language

M

Michael

Hi
how to automatically use different languages alike winehq.org etc.?
Many thanks
Michael
 
J

Jukka K. Korpela

how to automatically use different languages alike winehq.org etc.?

By imitating what they do.

But it's better not to do things that way.

Look at the page http://www.winehq.org and suppose that all Latin letter
are Greek... Hebrew... well, just _very odd_ to you. What would you do?

(Incidentally, I just a had a nice lunch conversation with my wife,
recollecting memories from our trip to Israel. We couldn't instruct a
taxi driver take us to a place we wanted, even by showing it on the map,
as the map texts were in those odd Latin letters - we have to proceed so
that she read names on the map aloud... I also remember when I first
tried to draw cash using an ATM where the initial display had Hebrew
letters only. And it was just a lucky guess, rather than my limited
understanding of the letters, that took me to a version of the user
interface in English. And I do remember the printed statement about
"royal bitch" in my credit card balance after using an ATM at the Royal
Beach hotel, but I digress.)

You might get the idea if you select the Hebrew language (I guess you
can guess what option it is), then consider what you would do if that
were the first page you encountered. (I'm assuming that you don't know
Hebrew. Try "Polski" if you do. If you know both languages, I'm sure you
realized what the problem is!)

The first point is that in a multilingual site, the main page
(corresponding directly to the server address) should contain
_something_ understandable in one's own language, if that language is
among the supported languages. A splash page of language selection, with
each language indicate in the language herself, is not ideal but surely
not the worst option.

The second point to learn is that a menu of languages should be a menu
of languages, not a menu of countries, still less a menu with distorted,
even insulting versions of country flags.

Apart from the bad use of flags, the page http://www.winehq.org/lang is
not too bad. And it's just a list of links, as it should be. You might
ask why it misspells "Current Langage" and "la Lengua" (Spanish uses no
such capitalization), but the answer is that people just don't take
these things seriously. At least the top level pages are left to
semialphabetic nerds.

And, of course, there is no true localization, as usual. If you select
the Spanish (Español) version, you'll see that most, if not all, pages
are served in English. It's often OK to user English as fallback, but
hardly ever OK to do so without warning. Any accidental-looking change
of language is suspicious, or should be.
 
J

Jukka K. Korpela

Beware of over-generalized assumptions...

I think you just confirmed my point. :)
It's often OK to user [sic] English as fallback

... because sometimes, even people who *do* take such things seriously
still fall prey to the occasional typo. :)

I do take localization seriously, but sometimes not seriously enough. My
typo, though a stupid one, is hopefully excusable in an informal
discussion like this Usenet group. On the front page of a web site, or
on the language selection page of a multilingual site, no excuses should
be accepted. It should not depend on the carefulness of a single person
or his mood.
 
S

Stanimir Stamenkov

Tue, 21 Jun 2011 11:31:01 -0700 (PDT), /Dan/:
I have some comments on this topic here:

http://webtips.dan.info/language.html

As far as I'm aware: "The Content-Language entity-header field
describes the natural language(s) of the intended audience for the
enclosed entity. Note that this might not be equivalent to all the
languages used within the entity-body."
... The primary purpose of
Content-Language is to allow a user to identify and differentiate
entities according to the user's own preferred language. Thus, if the
body content is intended only for a Danish-literate audience, the
appropriate field is

Content-Language: da

If no Content-Language is specified, the default is that the content
is intended for all language audiences. This might mean that the
sender does not consider it to be specific to any natural language,
or that the sender does not know for which language it is intended.

Multiple languages MAY be listed for content that is intended for
multiple audiences. For example, a rendition of the "Treaty of
Waitangi," presented simultaneously in the original Maori and English
versions, would call for

Content-Language: mi, en

However, just because multiple languages are present within an entity
does not mean that it is intended for multiple linguistic audiences.
An example would be a beginner's language primer, such as "A First
Lesson in Latin," which is clearly intended to be used by an
English-literate audience. In this case, the Content-Language would
properly only include "en".

So 'Content-Language' is not appropriate for specifying the language
of the content as specifying:

Content-Language: en

would mean: "intended only for native English speakers", while I not
being native English speaker could read English well enough to be
appropriate audience for the content.

I'm not really fond of the current 'Content-Language' intention as I
find it quite useless compared to the use of specifying the language
of the entity, but that's what has been really specified.
 
J

Jukka K. Korpela

"The Content-Language entity-header field describes
the natural language(s) of the intended audience for the enclosed
entity.

That's a sloppy wording in the HTTP protocol, and it gets worse:

It may sound like it referred to the native language. But in the next
statement, the idea is completely different:

Being "Danish-literate" is surely not the same thing as having Danish as
the native language. In fact, what the protocol means to say is obscure
but probably different from both of these. The Content-Language header
is not restricted to text documents. It could accompany a resource
consisting of recorded speech. I consider myself as fairly
"Danish-literate" but I understand very little of _spoken_ Danish.
So 'Content-Language' is not appropriate for specifying the language of
the content as specifying:

Content-Language: en

would mean: "intended only for native English speakers",

No, it does not mean that. The HTTP protocol just describes the header
poorly. What it wants to say, more or less, applied to this particular
case, is that the header informs that the resource is intended for
people who understand English, in some vague sense.

(It is hard to imagine a resource that would only be intended to
_native_ speakers of a language. I have met many people who have learned
Finnish as second language and speak it better than most native speakers.)

The HTML 4.01 specification explicitly says that in the absence of lang
attributes, the Content-Language header, if present, is to be taken as
specifying the language of the document.
I'm not really fond of the current 'Content-Language' intention as I
find it quite useless compared to the use of specifying the language of
the entity, but that's what has been really specified.

The topic is rather theoretical, because the Content-Language header is
used very little if at all by software that _could_ use it. (Apache
content negotiation uses Content-Language lines in configuration files,
but they are not HTTP headers as such - though they may cause such
headers to be sent, but with no practical impact.)
 
S

Stanimir Stamenkov

Wed, 22 Jun 2011 08:47:06 +0300, /Jukka K. Korpela/:
"The Content-Language entity-header field describes
the natural language(s) of the intended audience for the enclosed
entity.

That's a sloppy wording in the HTTP protocol, and it gets worse:
[...]
Content-Language: en

would mean: "intended only for native English speakers",

No, it does not mean that. The HTTP protocol just describes the
header poorly. What it wants to say, more or less, applied to this
particular case, is that the header informs that the resource is
intended for people who understand English, in some vague sense.

So, is it correct to say specifying:

Content-Language: <LN>

where <LN> is a two-letter language code, is always appropriate for
a content mainly written in the given language?
 
J

Jukka K. Korpela

So, is it correct to say specifying:

Content-Language: <LN>

where <LN> is a two-letter language code, is always appropriate for a
content mainly written in the given language?

That's the general idea, though it's not particularly _useful_ to do so.
On the top of my head, I can't figure out _any_ impact it could have,
except as documentation to a person who looks at the headers sent by the
server (e.g., using Web Developer Extension on Firefox - it's useful
even if you aren't a developer) and knows the meaning of this header.

But trying hard, one might find a counterexample. Imagine a document
consisting of 95% Etruscan texts and 5% notes in German, with the
purpose of testing that a font containing Etruscan letters is available
and has acceptable characteristics. The notes in German would explain
how to judge the acceptability, as well as tell the purpose, give
references, etc. So the reader is expected to know German, but he does
not need to know Etruscan. Then the correct value for Content-Language
would be "de". But in markup, it could well have <html lang="ett">, just
overriding this with lang="de" for the pieces that are in German.
 
B

Brian Cryer

<snip>

Whilst your comment is valid, are you aware that you are replying to a post
which is over a year old?

I suspect you are posting via a forum and are not aware that this is a poor
front end to a newsgroup. Do yourself a favour and get a newsgroup reader
and then look at the current discussions on alt.html.
 
S

Scott Bryce

And of course you also warn the user that cookies are used, and that
they should not empty their cookie-jar if they want to keep the
language setting in the future. :)

Or not. I suspect on a well-designed site selecting your preferred
language is not an overly burdensome task.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top