Re: Localized Pages

[Thom May <excession penguinpowered com>]

* Christian Rose (menthos menthos com) wrote on Sweetmorn, the 39th of The Aftermath, 3166 :
> Joakim Ziegler wrote:
> 
<!-- snip -->
> 
> 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.
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.
> 
> 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'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?" 
> 
> 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.
> 
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.
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
> 
> > 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.
I agree with both of you, actually. If there is a translation,
then it should be used, transparently. If there isn't, we should
(perhaps) explain that a translation is being prepared and then
give them the English.
> 
> 
> > 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.
Yup.
> 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.
Important ones - Gnome Foundation set up, etc - should be translated. 
Day to day, "oooh, gb v0.16 released" style gnotices postings shouldn't
be translated.
> 
> > 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".
That wasn't what Joakim said. he said "english is the _easiest_
language"(my emphasis). not whether people were trusted, or what
the quality of translation is.
> 
> > 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.
> >>> 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)...

Huh? Gnome.org is obviously not _just_ a free software site. 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?

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.

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. I'll ask the guys
at work (hey, working for a web design house has to have some
benefits ;-) ) what the usual procedure is...

<!-- snip -->
> 
> 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?
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]


> 
<!-- snip -->
> 
> 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.
> 
> 
> > 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).
> 
This is shredded as much as possible while still having context.
Sorry to every one else.
> Christian

-Thom