Continent/city translations

[Denis-de-Bernardy]

see #9758. we'd want a file that contains the full list of continents, cities, and subcities, for inclusion by xgettext

[Denis-de-Bernardy]

regexep foo'ed dump file as a starting point

[Denis-de-Bernardy]

second one should do the trick

[ryan]

(In [11290]) Translate continent and city names for timezone picker. see #9794

[ryan]

I dumped only the cities in our whitelisted continents. Other than that I think our lists are the same.

[Denis-de-Bernardy]

yup. mine was a mere starting point for you as a convenience. :-)

anyway, off to bed... if you've some time, please look into the user-related ticket (#9568, #9682, #9669) before it's too late. I'll back them with patches if issues arise (I honestly doubt any will), and they'll be a definite plus to 2.8.

[xibe]

Yeepee, 500 new strings in POT ;)

[demetris]

Is this a necessary burden on translations and translation teams?

Can’t we just say that these are international names or something, and leave them untraslatable?

Is there any feedback on this change from Nikolay or translation teams?

I nearly went into a fit today when I saw the 500 new strings! :-D

[xibe]

Replying to demetris:

Is this a necessary burden on translations and translation teams?

Can’t we just say that these are international names or something, and leave them untraslatable?

Is there any feedback on this change from Nikolay or translation teams?

I nearly went into a fit today when I saw the 500 new strings! :-D

Seeing 500 new strings to translate also burdens my work, but I fear saying "these are international names" is akin to saying "English is the international language of choice" - well, sort of.

Once you want to translate a tool, you want the whole thing to have "that local feeling", and not leave a part of it untranslated - albeit just a single form in a mostly un-explored part of the admin.

So yeah, currently I'm leaving these strings as-as for when I have the team to handle them all, but in the end I'll bite the bullet and do it: WP will feel that much more full-French once it's done.

We've all had to climb a steep hill when we first started translating WP, but it was all for the best. This tiny form brings much to do again, but again, it's all for the greater good.

[Denis-de-Bernardy]

doesn't the translation tool make the strings default to their english value?

[xibe]

Replying to Denis-de-Bernardy:

doesn't the translation tool make the strings default to their english value?

It depends on the tool I guess, but when updating the PO to the latest trunk POT in poEdit, it does the following:

• put around 270 cities strings as new/not translated - ergo, if not translated, WP will display them as-is;
• put around 180 cities strings as fuzzy - that is, it has tried to match the strings with other already translated strings, and it's up to you to make sure the match is adequate.

For instance, with the current fr_FR PO, it gives these fuzzy translations:

• Algiers -> lignes
• Dar es Salaam -> Marquer comme indésirable
• San Luis -> Chercher dans les liens
• Baku -> Sauvegarde de sécurité

And so on...

Obviously, not everyone uses a fuzzy-making tool such as poEdit, but it's enough to make translation a must-do. WordPress does defaults to the original string if no translation is found, but since the fuzzy strings ARE translation, that means unless the translateur deletes all the fuzzies, he'll end up with weird translations in that form instead of the original string.

Furthermore, for those who set their tool to not try to match fuzzy strings, they still have to deal with having these 500 cities strings untranslated in their PO. They'll be translating them sooner or later in order to get that number to zero - translator pride, y'know? :)

Therefore, either the core devs do not allow these strings to be translated for anyone, or the translators have to translate them all, but there is no middle-ground here, I think.

I, for one, vote for full-translation (ergo, the current status), even if it's gonna be a real pain in the neck to check them all up...

This should probably be decided in the wp-polyglots list. Nikolay, care to launch the subject? We can have a PollDaddy vote ;-)

[demetris]

@Denis:

No. Untranslated strings are empty in the PO file. (The defaulting to the English/Whatever value must be happening either when the PO file is compiled into a MO file or when the application—WP here— reads the MO file and finds empty strings. I haven’t checked.)

@xibe:

English IS the international language of choice. Organizations like ISO or the UN treat English and French as equal, e.g. see here:

<​http://www.iso.org/iso/country_codes.htm>

But, in actual reality, the lingua franca is English. If you ask a Greek person what is the international name of their country, they’ll reply: Greece, not: Grèce — unless you resurrect some educated person from the Thirties. :-D

I imagine this would not be very different with people from other countries.

Then, there are more practical problems:

Aside from the fact that, since I’m not going to translate 500 city names, I will now be seeing the unhelpful message “500 untranslated and 10 fuzzy” — instead of “10 untranslated and 10 fuzzy” which helped me know where I was at...

How is the sorting problem going to be solved? Now translated strings sit at the same order their English original were. That’s a problem. But trying to solve it will cause other problems...

My suggestion:

Drop this file, or, at most, make a separate POT with the city names and then load localized city names (if they exist) with a new constant in wp-config.php.

NOTE:

What I’m saying does not come from indifference to the L10n issue. Localization of services and products is one of the things I care about the most, and I’m proud to have helped bring the Greek WP L10n to a completion state of about 99.5%, all in clear, plain language. But I also try to be realistic and practical.

[xibe]

Replying to demetris:

But, in actual reality, the lingua franca is English. If you ask a Greek person what is the international name of their country, they’ll reply: Greece, not: Grèce — unless you resurrect some educated person from the Thirties. :-D

Obviously :) But not every blogger in Albania will understand all city names. Granted, they don't have to in order to get their blog going.

That's why this huge number of new strings (and the accompagnying workload for translators) seems painful in comparison with actual usefulness.

Therefore...

Drop this file, or, at most, make a separate POT with the city names and then load localized city names (if they exist) with a new constant in wp-config.php.

...I'd more than happily support this motion, if do-able (Nikolay?). This new MO file could be put by translators in the /dist/wp-admin/ folder of their respective repositories, just as they already do for setup-config.php and a ​bunch of other un-gettest'd files.

Core devs, not all i18n team can keep up with the pace, and making their burden heavier with so many strings of imperceptible usefulness can only slow them down. Then again, some translators WILL want these strings translated. So demetris' suggestion looks like a fine compromise between need and availability.

[ryan]

I wouldn't mind a separate pot, if someone can work up a patch. These strings are currently used for one page and are not needed elsewhere. Regardless, the strings do need to be available for translation.

[Denis-de-Bernardy]

an updated cities/continents file with a custom text domain, and a load_plugin_textdomain call on that page only, right?

[ryan]

Something like that. We'd also have to change the xgettext scripts Nikolay uses to exlude these strings from the main pot and put them in another. We can take care of that separately.

[demetris]

Replying to ryan:

I wouldn't mind a separate pot, if someone can work up a patch. These strings are currently used for one page and are not needed elsewhere. Regardless, the strings do need to be available for translation.

If the strings are made available for translation, in whichever way, then the sorting problem has to be solved too.

Because, if we suppose it’s bad leaving such strings untraslatable, it’s worse making them translatable and sorting them according to the English originals: Then, to find the place of a city in the list, you’ll have to guess its English name first.

Then again, if the list is in some way sorted, it will be confusing if not all strings are translated (very realistic scenario), especially for languages that don’t use the latin alphabet, because the untranslated strings will be in one place and the translated strings in another. And how are you to know in advance if the name of the place you look for is or is not translated?

[ryan]

Sort by translated names

[ryan]

Sort by translated names, load continents-cities mo file

[Denis-de-Bernardy]

fix bug in 9794.2.diff

[Denis-de-Bernardy]

uploaded a slightly different diff. translate("$city/$sub_city") won't match anything.

[Denis-de-Bernardy]

if you've a means to ignore a file with xgettext, I believe this should work out of the box.

[Denis-de-Bernardy]

fix typo in 9794.3.diff

[Denis-de-Bernardy]

one point we haven't looked at, though, is this: is the list the same on all systems? :D

[ryan]

(In [11332]) Sort tz continents and cities by translated names. Load translations from separate mo to avoid cluttering default pot. Props Denis-de-Bernardy. see #9794

[Denis-de-Bernardy]

k, just noticed this in the logs:

[20:13] <nikolayb> rboren: it may cause also other infrastructure changes, but I really don't want all these cities in the main POT

so will make the domain explicit in that file.

[Denis-de-Bernardy]

make the domain explicit, to simplify their extraction by nikolayb

[Denis-de-Bernardy]

there you go.

[Denis-de-Bernardy]

per discussion on IRC

[Denis-de-Bernardy]

[21:19] <nikolayb> and I also need load_textdomain code, which loads the MO from locale-contient-cities.mo if present
[21:20] <ddebernardy> ​http://core.trac.wordpress.org/attachment/ticket/9794/9794.6.diff
[21:25] <nikolayb> ddebernardy: exactly, I didn't see that rboren already id that
[21:26] <ddebernardy> I do suspect that the 9474.5.diff is good enough, though
[21:27] <ddebernardy> we'd merely need to exclude the 'default' domain, which is implicit on other calls

[Denis-de-Bernardy]

which then gets confirmed, so 9794.5.diff is the one to use indeed.

"the tool, which extracts the strings looks only the first arg of , so .5 doesn't make absolutely any difference"

[Denis-de-Bernardy]

adds this, though: <nikolayb> we can go without another domain, but if for some reason strings overlap we can get the wrong translation

[nbachiyski]

Use continents-cities domain

[Denis-de-Bernardy]

same as previous patch, with cities list

[ryan]

(In [11333]) Give continents-cities their own textdomain. Props nbachiyski, Denis-de-Bernardy . fixes #9794

[xibe]

Thanks a lot to all those involved!

Now, a few details before parting our separate ways:

• Where will translators get that new POT? In ​the usual place?
• Where will the resulting MO file have to be put in /dist/ in order for it all to work? Will there be any more setting to put in place, like in wp-config.php?
• (i had a third one, not a question, but forgot about while writing the two above. oh well)

[Denis-de-Bernardy]

​http://core.trac.wordpress.org/changeset/11333#file1

the language file will into wp-content/languages/

for the other question, whoever runs the server would need to answer, but based on the IRC chat I can only assume it'll appear in the usual location, yeah.

[nbachiyski]

Replying to xibe:

Thanks a lot to all those involved!

Now, a few details before parting our separate ways:

• Where will translators get that new POT? In ​the usual place?

It's already there.

• Where will the resulting MO file have to be put in /dist/ in order for it all to work? Will there be any more setting to put in place, like in wp-config.php?

Nope.

[xibe]

Replying to nbachiyski:

It's already there.

Yup, seen it this morning, already taken care of - at least for the continents :)

• Where will the resulting MO file have to be put in /dist/ in order for it all to work? Will there be any more setting to put in place, like in wp-config.php?

Nope.

Excellent news!

[demetris]

Thanks for taking care of this, Denis and Ryan!