[Fwd: [webmasters] Web page dates -- Please prefer ISO 8601 standard]

[Sophie Gautier-2]

Hi,

May be it's an idea to use ISO date in the documentation written in
English ?

Kind regards
Sophie


At page:

   http://documentation.openoffice.org/manuals/userguide3/

The Dates are expressed in numeric + verbal notation which is
difficult for reader to read understand. The non-english speaking
people (like me) have hard time counting in in their heads if March is
before April or was it the other way round etc and if September goes
before October, so on, so on.

SUGEGSTION

Please present dates in web pages using ISO 8601 syntax:

       YYYY-MM-DD HH:MM

       http://en.wikipedia.org/wiki/ISO8601

This format is:

- Internationally known standard and
  has uniform interpretation
- Works for any nationality and for visitors coming outside of the Web
  page's recidence.
- Is easy to tell quickly which the month order is.

Thanks,
Jari




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[ccornell - OpenOffice.org]

> May be it's an idea to use ISO date in the documentation written in
> English ?
[snip]
>        YYYY-MM-DD HH:MM

...which subsequently confuses people who use DD-MM instead of MM-DD.

Personally, after having lived in Europe for several years, and becoming
used to date conventions used here, I'd read a date written; 2009-11-08
as 11 August 2009, not 08 November 2009 as it would be according to ISO8601.

This problem is illustrated by: http://www.w3.org/QA/Tips/iso-date
(where it discusses both the problem of using numbers, and the issues of
crossing languages and cultures).

Also worth reading on this is:
http://www.w3.org/International/questions/qa-date-format
including the Pros and Cons of ISO8601.

The Summary on this page comes to the same conclusion I've come to in
the past:

(quoting)
"If there is likely to be any ambiguity on the part of the user, it is
usually best to use explicit month names and 4-digit years for Gregorian
dates, or at least indicate on the page how to read the dates."

My thoughts on this... if we do switch to ISO8601 date formats, then we
would need to be explicit about it - stating exactly what date format is
being used.

Anyone else have any thoughts on this?

C.
--
Clayton Cornell       ccornell@...
OpenOffice.org Documentation Project co-lead
StarOffice - Sun Microsystems, Inc. - Hamburg, Germany

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[T. J. Frazier-2]

Clayton wrote:

>> May be it's an idea to use ISO date in the documentation written in
>> English ?
> [snip]
>>        YYYY-MM-DD HH:MM
> [snip]
>
> My thoughts on this... if we do switch to ISO8601 date formats, then we
> would need to be explicit about it - stating exactly what date format is
> being used.
>

If we simply repeat some information, we could represent those dates as
2009-08-11 (Aug 11)
which is unambiguous for all languages and locales. Even a non-English
speaker should correctly note which number has been changed to a month name.

BTW: wouldn't this whole page be better on the wiki, for easier
updating? Not to mention localizing.

--
/tj/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jean Hollis Weber-3]

T. J. Frazier wrote:

> Clayton wrote:
>>> May be it's an idea to use ISO date in the documentation written in
>>> English ?
>> [snip]
>>>        YYYY-MM-DD HH:MM
>> [snip]
>> My thoughts on this... if we do switch to ISO8601 date formats, then we
>> would need to be explicit about it - stating exactly what date format is
>> being used.
>>
> If we simply repeat some information, we could represent those dates as
> 2009-08-11 (Aug 11)
> which is unambiguous for all languages and locales. Even a non-English
> speaker should correctly note which number has been changed to a month
> name.

That is a good idea and an easy solution to the problem.


> BTW: wouldn't this whole page be better on the wiki, for easier
> updating? Not to mention localizing.


Clayton may correct me on this, but I believe that this page, and all
the associated PDF files, are on our list for migration to the wiki,
as part of a general rationalisation of the way documentation is
provided. That is, the user guides, like the developers' guides, will
then be available in downloadable form through the wiki... even though
(at least for the immediate future) the source docs for the UGs will
continue to be ODT files residing on the OOoAuthors website, with the
the wiki version derived from the ODT version instead of the other way
around as for the developers' guides.

--Jean

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[ccornell - OpenOffice.org]

>> If we simply repeat some information, we could represent those dates as
>> 2009-08-11 (Aug 11)
>> which is unambiguous for all languages and locales. Even a non-English
>> speaker should correctly note which number has been changed to a month
>> name.
>
> That is a good idea and an easy solution to the problem.

Yup, good solution... I like it :-)

As a first attempt at it, I fixed up the dates on this page:
http://wiki.services.openoffice.org/wiki/Documentation/Wiki_Books
using the suggested format.  Looks OK to me.


> Clayton may correct me on this, but I believe that this page, and all
> the associated PDF files, are on our list for migration to the wiki, as
> part of a general rationalisation of the way documentation is provided.
> That is, the user guides, like the developers' guides, will then be
> available in downloadable form through the wiki... even though (at least
> for the immediate future) the source docs for the UGs will continue to
> be ODT files residing on the OOoAuthors website, with the the wiki
> version derived from the ODT version instead of the other way around as
> for the developers' guides.

It is definitely easier to maintain the content via a Wiki page vs the
older html page style (requiring CVS access etc.)  We can upload the
ODTs and PDFs to the Wiki, and/or upload them to the OOoAuthors
repository (is there one?), and then link them via a master doc page -
the result is the same - a single page listing downloadable docs for an
OOo release family.

We can do the same from the main Documentation page.. instead of a link
to an html page listing the available docs, I can change that to a link
to the Wiki page (once it's in place) showing the same info.

C.
--
Clayton Cornell       ccornell@...
OpenOffice.org Documentation Project co-lead
StarOffice - Sun Microsystems, Inc. - Hamburg, Germany

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Nino Novak-2]

On Wednesday 11 November 2009 10:54, Clayton wrote:
> >>  2009-08-11 (Aug 11)
...
> http://wiki.services.openoffice.org/wiki/Documentation/Wiki_Books

Clayton, 3 = March, not April ;-)

SCNR Nino

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jean Hollis Weber-3]

Clayton wrote:

> Jean Hollis Weber wrote:
>> Clayton may correct me on this, but I believe that this page, and all
>> the associated PDF files, are on our list for migration to the wiki, as
>> part of a general rationalisation of the way documentation is provided.
>> That is, the user guides, like the developers' guides, will then be
>> available in downloadable form through the wiki... even though (at least
>> for the immediate future) the source docs for the UGs will continue to
>> be ODT files residing on the OOoAuthors website, with the the wiki
>> version derived from the ODT version instead of the other way around as
>> for the developers' guides.
>
> It is definitely easier to maintain the content via a Wiki page vs the
> older html page style (requiring CVS access etc.)  We can upload the
> ODTs and PDFs to the Wiki, and/or upload them to the OOoAuthors
> repository (is there one?), and then link them via a master doc page -
> the result is the same - a single page listing downloadable docs for an
> OOo release family.
>
> We can do the same from the main Documentation page.. instead of a link
> to an html page listing the available docs, I can change that to a link
> to the Wiki page (once it's in place) showing the same info.

Excellent! That would make my life SO much easier, not having to deal
with CVS (especially since I use multiple computers).

OOoAuthors does have a repository of sorts, but I think that website
is best kept as a workspace for people developing the user guides, and
avoid sending users there to collect documentation.

(We have not been allowed to put the ODT source files for the user
guides on the Docs website due to their CC:BY license, but we can put
them on the wiki along with the PDFs.)

Yesterday I started a discussion on the OOoAuthors list about some
technical/tracking problems associated with maintaining a set of
published docs accessible to the public. The only solution that has
occurred to me is cumbersome. Avoiding the problem is much better.

--Jean

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[ccornell - OpenOffice.org]

Nino Novak wrote:
> On Wednesday 11 November 2009 10:54, Clayton wrote:
>>>>  2009-08-11 (Aug 11)
> ...
>> http://wiki.services.openoffice.org/wiki/Documentation/Wiki_Books
>
> Clayton, 3 = March, not April ;-)

Ha.. ooops :-)  Fixed.

C.
--
Clayton Cornell       ccornell@...
OpenOffice.org Documentation Project co-lead
StarOffice - Sun Microsystems, Inc. - Hamburg, Germany

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...