GNOME.org
 

Re: Localized Pages

Thom May wrote:


But, if we don't provide translations to languages other than
"core" gnome ones, how do we attract more people from these
countries to work on gnome. We _have_ to try to attract as many
people as possible.
Yes, but existing translation resources *are* limited. With that I mean that there is only a finite (not infinite) number of people working on translating GNOME at present. :-)
I think maybe you misunderstood how translations work in GNOME. There is no concept of "core" languages (languages that *has* to be supported). Instead, languages are supported on a "need" basis. If a person thinks that it really sucks that GNOME isn't availiable in Klingon, he goes to the gnome.org pages, reads about the GNOME translation project, and reads the instruction about how to create a Klingon translation team and provide Klingon translations. Eventually, he will have company by others who also thinks the same about Klingon and want to help. There is no mandatory "you should do this and that". This is the "scratch an itch" concept in free software. All current GNOME translations have become reality because of this. If you want a translation that doesn't exist, go ahead and do one.
So I think that people that want a translation for a new language in GNOME, or add a new language translation to the web pages, could still be directed to the GNOME translation project. You're perfectly free to do just one module translation (in this case the module would be "gnome_web" or something like that :) if that is the only thing you want to do.
I've counted the "languages" that are specific to country in the GNOME project. It is: bg_BG, en_GB, pt_BR, zh_CN and zh_TW. 

Urr, how do you arrive at that? That's excluding the US, Sweden,
France, Germany, etc etc.
That was the languages that are bound to a country. The Swedish translation team doesn't differ between sv_SE (Swedish used in Sweden) and sv_FI (Swedish as used by a minority of the population in Finland). This is because no one has yet showed interest in doing a special sv_FI translation. Hence, the Swedish team is just "sv" and both Swedish and Finnish users that choose Swedish as the language will get the same translations. The situation is the same for other 35 languages I failed to mention. I hope this explains what I meant with "country-specific" translations and that there are currently only 5 of those.
That's 5 out of a total of 40 languages. That's what I meant with the "most" being not country-specific, and where we simply can cut the country part in the locale string, since it is of no use to us since we don't have a special translation for that country anyway, and only keep the language part. 

Well, instead of going, "ok, we don't _already_ have a
translation team, screw em", why isn't "ok, we _need_ a
translation team for $COUNTRY, how do we find one?" 

By people interested in doing those translation doing those translations :)
We're happy for more languages, but there has to be somebody doing it. A language team is by definition started when the first person says "ok, I want a translation for $LANGUAGE, how do I do that?" to the translation project. That person will instantly become that translation team leader. 



Ah, but browsers sending the correct language shouldn't be
relied on. If you can set a cookie, that will always be right,
and will reflect the _user's_ choice, not the browser's,
however the browser is configured. Esp given the fact that I'd
be willing to put money on the fact that a huge proportion of
MSIE users browse with en_US set, whereever they're from.
Yes. But if the international user has en_US set, how on earth are we going to know that he in reality wants another language? We don't have an AI that can read minds yet :) The automatic language detection is a way to help those users that *have* the language preference set to another language than English and thus wants it that way. That's the best we can do.
However, if the user choses another language on the gnome page, I agree that the automatic language detection should not be used after that, but only the cookie with the language preference. 



And the user is not particularily likely to notice the cookie
overhead over PHP. If your worrying about fetch speeds on a itty
bitty cookie, then the line is liekly so congested that the user
won't notice
Maybe you're right. Come to think of it, yes. However, that's an implementation issue, not a design issue like if we should use translations by default or not. But I think I agree with you. 


[snip]


Hence, the chance of the page looking unrepresentative because of erroneous
language, etc. is the smallest if we default to English.
I don't understand this. Your statement assumes that no one ever does QA on non-English languages. That's not true at all. 

No it doesn't. see above, but the point is that all info is put
out as english first, and there fore the english is by default
_right_ -  ie it's the base the translations are made from. When
a page has gone from, as an example, english -> swedish, there are
_bound_ to be errors because no one is perfect. That (I think)
is _all_ that Joakim was saying.
And that is not a new problem. It is called "translation QA" and is what I meant. It includes checking if the translation is identical to the original in content (and also if the translation is well written according to the translation language's rules). This is what is done all the time by the translation teams on their own translations (and by Sun :), or occasionally by users reporting errors. I still fail to see how this is any different from software translation. 



Huh? Gnome.org is obviously not _just_ a free software site.
Then what is it? Don't tell me GNOME suddenly isn't free software? Call in RMS! ;-P 



and why is a free software site any different to a commercial one.
Or a non money making site any different to  money making site?
Because the organization behind it and the intentions differ. GNOME isn't a multinational corporation that has subsidaries in many countries, and that markets "the product" in those countries, for example. That means we can't have a fancy web portal in every country with localized content, nor can we have people who market the local URL, instead of the global URL, in newspapers and advertisements. This means people won't expect to have to go local versions of the site to get translations when they want to go to the site the first time, because they don't even know that the local version exists in the first place. 



And who cares what any one else does? Gnome is a leader, not a
sheep. And that has to come through in everything it does.
Yes, why do we have to follow commercial sites by not providing translations by default? 



If we can get localisation detection working, then we should use
it. If we can't, it would be better to not use it, and present
the user with a choice when they hit the site.
For various reasons already discussed, the language choice should still be presented either way, I think. The automatic detection is just so that you don't *have* to use the language selection.
When it works, you'll get the language you wanted. When it doesn't work, you'll get the fallback language (English). Seems rather simple to me. This is what SourceForge does. When it fails, we have done the best we could, but when it succeeds, we have helped the user. I think the proposal of always using English is like saying that we should *always* fail because if we tried to succeed we *might* fail... 

So your argument that people don't want english is suddenly
thrown out the window because of a technical hitch?
No, but in the cases where the language preference is not set, we have no possibility at all(*) to automatically determine what language the visitor wants when he goes to the site the first time. See my comment about the lack of AI above ;-)
But when the visitor has this, we have the chance to give him the language that he wants. That is what I meant. And always defaulting to English, regardless of language setting, would be ignoring that chance.
(*) A hack is to try to determine wanted language based on the visitor's host TLD, but that is *very* nasty. Should be avoided, IMHO. 



What would, imo, be the right thing to do, and please excuse the
ascii art is to have something like this:

[Language Test]
	|
	[Check for preset cookie] - [if present, do site]
	|
	[Browser Language] -- [if works, set language cookie, whack up site]
		|
		[if not]
		    |
		    [display selection of languages imediately,
		    set cookie, do site]
Seems reasonable. My only objection is that the manual language selection should be a part of the front page design, not shown as a "splash screen" that you *have* to choose if automatic detection fails. Many people think splash screens, intro pages and the like are very annoying.
However, if you *have* chosen a different language, you'll get that, but if it didn't work, you'll still get the English page. No harm done, but we have at least tried to do what you wanted. I'm having trouble seeing how this could be harmful. 

Because you're stilling pissing off people who don't want
english but don't know how to change their browser settings.
They have to be presented with a choice ASAP.
And that they will get, on the front page. I don't know if you misunderstood me, I have never been against a manual choice to override the language setting. I have always been of the opinion that a language selection option that overrides the defaults should be clearly visible on the front page. 


Christian
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]