- From: Tex Texin <tex@i18nguy.com>
- Date: Tue, 10 Jun 2003 04:21:42 -0400
- To: GEO <public-i18n-geo@w3.org>
Lloyd, Here are comments on http://www.honomichl.com/qa-date-format.html 1) looks very good! Most of my comments are on minor points. 2) On the comment that 8601 is computer friendly, I think it is also useful to users, that sorting appears naturally-ordered. 3) 8601 is not people unfriendly. I think it is very natural. Perhaps we can say that people may prefer native formats. 4) There is a third approach: declare the date format being used. For example: Today is 03/02/01 (yy/mm/dd). Where this may be most useful is to alleviate the con about space in tables. If you add the declaration, then the space requirement can be reduced while maintaining y/m/d for universality: date1 date2 (yy/mm/dd) (2003/mm/dd) 03/02/01 02/01 03/02/02 02/02 ... Note, the declaration for most pages only needs to be mentioned once per page to indicate "this page presents dates in this format yyyy-mm-dd", perhaps as a footnote or in the introductory remarks. 5) I am not sure about including the info on the possibility of a date tag. Why should we present this? What should people do with the information? (can they indicate they approve or disprove?) Perhaps this was due to confusion about the date-declaring approach #4 above. I had used the phrase "to tag" the date, by which I mean present in the text which format is being used. 6) Is it worth mentioning that capitalization rules vary by locale and this can affect how months are presented? 7) The introduction says: "The separators may be slashes, dashes or periods. Some locales print leading zeroes, others suppress them." but the page doesn't really say anything about handling this. Should we comment on how important this is? Do the programmatic solutions adequately address this? Is it worth mentioning that Asian languages might use asian characters as separators and that the separator may vary between y, m, d? 8) accept-language often gives a list of preferences. Suppose the list is "en; q=1.0, fr; q=0.5". Suppose the page returned is fr. But en has a higher q, should the en date format be used or the fr? Should the date format be consistent with the content-language as opposed to the accept-language? 9) Perhaps we should offer a javascript routine? This is probably simpler for people to use since it doesn't require server changes. 10) should pros and cons of accept-language approach be listed as it is for the universal date format? Something like: pro- may be closer to user's culture, allows page in one language to represent more than one culture (I don't buy the en-US en-UK example of only the date changing) con- accept-language is meant to only select language. It is not necessarily indicative of date or other formats. -- ------------------------------------------------------------- Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com Xen Master http://www.i18nGuy.com XenCraft http://www.XenCraft.com Making e-Business Work Around the World -------------------------------------------------------------
Received on Tuesday, 10 June 2003 04:22:32 UTC