Re: SV: Klingon on Unicode site?

Yes but HTTP headers are still not part of the page content itself. It
is unrelated and only needed for the HTTP protocol and management of
caches inclding in proxies. Those headers are by definition not
translatable by the server. Only the brower may opt to display these
headers outside of the page content, using the user's preferences in
his browser.

So even if there's a visible 'Last modified" date included in the
content, it does not have to match the date indicated in the HTTP
header (which may be updated only for technical reasons unrelated to
the content itself, such as fixing an HTML syntax, or CSS style, or
the broen URL to a script or image, or because the querying user has
changed his preferences on his personnal account on that site in such
a way that the surrounded UI (sent as part of the personalized page
content body) needs to be refreshed, without affecting the date of the
content itself.

Both dates (in HTTP headers or in the page content body) are
unrelated. Standard HTTP headers are not translatable.

Le 4 avril 2012 00:07, Asmus Freytag <asmusf_at_ix.netcom.com> a écrit :
> On 4/3/2012 1:49 PM, Elsebeth Flarup wrote:
>
>>If the visible display of the value of the Last-Modified header (which may
>> or may not reflect the actual last modification time) is regarded as useful,
>> it should of course be in the same language as the rest of the page.
>
> I completely disagree. There may be many applications and web pages that are
> not translated into my preferred language, but I still want to be able to
> use my regional preferences. Especially common for US English apps and sites
> - I am entirely happy to use the English language UI, but I am very unhappy
> if I cannot see sensible dates with a dd/mm/yyyy order, a calendar where
> Monday is the first day of the week, and numbers where the decimal separator
> is a comma, just to mention the most common issues.
>
> For dates, there are two things affected by the locale. One is the language
> of the names of day and month. The other is the regional preference for
> their arrangement (date order).
>
> I can certainly sympathize with the view that the effect of these on the
> user (foreign or non-native user, to be more precise) is different.
> Switching between two different arrangement (especially short date formats)
> can indeed be more confusing than switching languages. However, for long
> data formats, getting the day month names in other scripts/languages than
> rest of the page is irritating in another way - and users do complain about
> it.
>
> Given all this, I still don't think it makes sense to alternate the format
> randomly based purely on whether the date is generated on the fly or during
> page edit.
>
> The latter is the situation for the Unicode site. Many pages have a date
> (see all the reports) in the header, which is static and formatted according
> the document locale (to use that term). The "last updated" date happens to
> be generated at runtime, because that is a convenient way to do it, but
> there's nothing intrinsic that requires it to be dynamic. (One might imagine
> some hypothetical alternative editorial process that would create a static
> time stamp at file upload).
>
> Therefore, overall consistency would suggest that exposing the dynamic
> nature of this particular string to the user by localizing it differently is
> a bug or poor design) and not a feature. Worse, on pages that have both a
> static and a dynamic date, using different formatting rules could create
> confusion. (The worst case scenario would happen if they were both in short
> date format).
>
> On the other hand, I can see situations where it might make sense to
> localize date formats even for an untranslated site. Those situations
> revolve typically around user input, but they don't apply here.
Received on Tue Apr 03 2012 - 18:05:40 CDT