GNOME.org
 

Re: Localized Pages

Joakim Ziegler wrote:
However, this is trivial to fix. For most languages, we don't need a particular country code (since we don't have specific translation for that country, just for languages), so it's just a matter of stripping the last country code part and only use language code. Problem solved. Not a very advanced programming hack, and it has been done before. 

People in a lot of very large countries would disagree with you. Like the
whole of Latin America (including Brazil), Canadian, Carribbean and African
French users, etc., etc. Not to mention the enormous number of English
variants used around the world.
When I said "for most languages" I thought of "for most languages that we will most likely be providing translations for"; that is, for most languages that have a GNOME translation team already, since web page translation will probably be handled by the GNOME translators. I'm sorry if that caused any confusion.
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. 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. However, for the locales mentioned above with a country part, it would of course be natural to preserve the information, since there would be use for it in determing the correct translation.
Actually, I think setting a cookie is only necessary if the user switched language manually (then we know that he is not satisfied with the detected language). Only then, we must explicitly remember his choice. In all other cases the language detection obviously worked and there is no need to set a cookie. 

The cookie is also handy to set to avoid complex language detection code in
all pages.
Maybe. I still don't think it would be complex; grabbing the language preference is no extra work at all because it is already sent by the browser with the page request, and most of the work with the preference would be chopping a short string and a simple case switch. I don't think it is much overhead compared to reading a cookie all the time, a cookie that we have to fetch from the client, while the PHP code would execute as fast as the web server possibly can. 



There are a couple of other reasons as well that I'd very much like the main
page to be in English no matter what. First of all, with the proposed
structure of translation (checkins lead to mails being sent out to
translators), the translations would likely trail behind the English pages by
up to several days.
Yes, translations are not instant. But most of the content on gnome.org aren't news, and so it doesn't matter if there for a couple of days is only an English text -- the important thing is that the other couple of months that text is present, translations will exist. 



Since a lot of people (especially new visitors) are
likely to go to www.gnome.org as a result of press coverage, it's extremely
important that the default for new users is the most up to date edition.
Those parts that don't have a translation yet are presented in English. We shouldn't hide information from the visitor just because he/she wanted translations were such exist. This is how it works in software; if there is no translation, English is shown. Besides, I have never seen the point in, or argued, that news and press releases should be translated. I don't think there will ever be manpower for, or interest in, the translation of ever-changing content. Maybe I'm wrong in that, but just to put it clear, I have never argued that we should do that, and I don't think that it is relevant to the discussion of enabling translations per default or not. 



Also, English is clearly the language it's easiest to do good Quality
Assurance of, since it's the language most people involved in GNOME speak.
So GNOME translators are trusted to do correct translations of all GNOME software, but they aren't trusted to translate the GNOME web site correctly? We were recently offered help from Sun with professional translation QA, we accepted, and the Sun person thought our Swedish translations were very good. I don't understand why the web page translation should have to be any different and why the quality procedures should have to be any different than the actual "product". 



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. 



Automatic language detection is not used by any large, successful commercial sites,
Why does it have to be commercial to count as an example? SourceForge is a large web site, but it isn't commercial, and localization obviously works for them. 

Ok, then. Large sites, successful sites. SourceForge is by no means large in
comparison to the examples I gave. No free software sites are, actually,
including Slashdot.


Will gnome.org suddenly be a large, successful, commercial site? ;)
To me it's a free software site; the site for a large and successful free software project, but it ain't commercial (yet)...
And if you look at other free software sites, translations are common (SourceForge, Debian etc). 



Notice that I haven't argued against localization of the main site. I think
we agree that this is important.
But we don't agree about how important it is. I think not enabling translations by default is saying that they aren't that important, by letting the people who want them, or even need them, have to click additionally on the page, just to get what they need or want and have already specified that they want. 



We're currently arguing about how much
weight to give to the little supported (by browsers in general)
Little supported? All Netscape 4.x versions support this (I think even Netscape 3.x does, but I haven't tested), Mozilla, Netscape 6, and all Internet Explorer versions that I know of. I don't know about Opera and Konqueror, but they probably support this too. No, lynx doesn't support it, but I doubt that a large part of the gnome.org will use lynx, and those who will try the adventure of viewing a site with lynx can probably cope being presented with an English default.
Apart from lynx, I don't think the browser support above suggest that this is "little supported". And for those few browsers that don't support it, nothing will be different from your proposal. 



and seemingly (to me) error-prone mechanism of Accept-Language: HTTP headers.
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... 



Please do not erect a strawman and claim that I'm opposed to localization.



I find it very important, and I also find it very important that it's done in
the way that gives the least amount of surprise for the users, in accordance
with good usability principles.
I've never suggested that you were against it. On the contrary, I was very impressed about your great initial enthusiasm about localization.
About the usability principle, yes, it is very nice. I see the usability issue in the perspective that if you have already selected a prefered language in your preferences, it is nice if sites that have translations will use that and not have to ask you again what you wanted (quite annoying). Also, for people not understanding English or having trouble with English, it is definately a usability help not to have to browse the page just to correct the site design error with showing you an English default. 



The reason the scenario isn't reversible is that people generally, by
convention, expect there to be a language choice on sites that show up in
English. English-speakers generally *don't* expect to come to non-English
sites in the .com, .org and .net TLDs and have to look for a language choice,
and as such, they're much more likely to leave.
But your example with the Polish page was a bug! Normally, the fallback language should be English. If you haven't tampered with your language settings in your browser and use an English-language browser, the page, according to the proposal, will be displayed in English, since English is the fallback language. 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. 



Would you mind trimming your replies down a little? I've tried to do so here,
but it's difficult to distill your thoughts, for me, and frankly this thread
is getting so long that it's hard for me to find the time to reply to it, and
it's certainly a nuisance for other listmembers as well.
I've tried to do that. However, it is hard to express the opinions, suggestions and motives in just a couple of sentences, at least to me. I also think the problem is more the amount of traffic in this thread than the length of the replies (but I could of course be wrong). 


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