WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#9794 closed defect (bug) (fixed)

Continent/city translations

Reported by: Denis-de-Bernardy Owned by: Denis-de-Bernardy
Milestone: 2.8 Priority: normal
Severity: normal Version: 2.8
Component: Date/Time Keywords: i18n
Focuses: Cc:

Description

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

Attachments (10)

continent-city-dump.txt (11.9 KB) - added by Denis-de-Bernardy 6 years ago.
regexep foo'ed dump file as a starting point
continent-city-dump.2.txt (8.5 KB) - added by Denis-de-Bernardy 6 years ago.
9794.diff (1.1 KB) - added by ryan 6 years ago.
Sort by translated names
9794.2.diff (1.6 KB) - added by ryan 6 years ago.
Sort by translated names, load continents-cities mo file
9794.3.diff (2.3 KB) - added by Denis-de-Bernardy 6 years ago.
fix bug in 9794.2.diff
9794.4.diff (2.3 KB) - added by Denis-de-Bernardy 6 years ago.
fix typo in 9794.3.diff
9794.5.diff (21.2 KB) - added by Denis-de-Bernardy 6 years ago.
make the domain explicit, to simplify their extraction by nikolayb
9794.6.diff (26.4 KB) - added by Denis-de-Bernardy 6 years ago.
per discussion on IRC
9794.7.diff (2.8 KB) - added by nbachiyski 6 years ago.
Use continents-cities domain
9794.8.diff (28.8 KB) - added by Denis-de-Bernardy 6 years ago.
same as previous patch, with cities list

Download all attachments as: .zip

Change History (42)

@Denis-de-Bernardy6 years ago

regexep foo'ed dump file as a starting point

comment:1 @Denis-de-Bernardy6 years ago

second one should do the trick

comment:2 @Denis-de-Bernardy6 years ago

  • Keywords has-patch added; blessed removed
  • Owner set to ryan
  • Summary changed from Todo: continent/city translations to Continent/city translations

comment:3 @ryan6 years ago

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

comment:4 @ryan6 years ago

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

comment:5 @Denis-de-Bernardy6 years ago

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.

comment:6 @ryan6 years ago

  • Resolution set to fixed
  • Status changed from new to closed

comment:7 @xibe6 years ago

Yeepee, 500 new strings in POT ;)

comment:8 follow-up: @demetris6 years ago

  • Cc dkikizas@… added
  • Keywords 2nd-opinion added
  • Resolution fixed deleted
  • Status changed from closed to reopened

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

comment:9 in reply to: ↑ 8 @xibe6 years ago

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.

comment:10 follow-up: @Denis-de-Bernardy6 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

comment:11 in reply to: ↑ 10 @xibe6 years ago

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 ;-)

comment:12 follow-up: @demetris6 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

@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.

comment:13 in reply to: ↑ 12 @xibe6 years ago

  • Keywords i18n added; has-patch removed
  • Owner changed from ryan to nbachiyski
  • Status changed from reopened to assigned

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.

comment:14 follow-up: @ryan6 years ago

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.

comment:15 @Denis-de-Bernardy6 years ago

  • Owner changed from nbachiyski to Denis-de-Bernardy
  • Status changed from assigned to accepted

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

comment:16 @ryan6 years ago

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.

comment:17 in reply to: ↑ 14 @demetris6 years ago

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?

@ryan6 years ago

Sort by translated names

@ryan6 years ago

Sort by translated names, load continents-cities mo file

@Denis-de-Bernardy6 years ago

fix bug in 9794.2.diff

comment:18 @Denis-de-Bernardy6 years ago

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

comment:19 @Denis-de-Bernardy6 years ago

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

@Denis-de-Bernardy6 years ago

fix typo in 9794.3.diff

comment:20 @Denis-de-Bernardy6 years ago

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

comment:21 @ryan6 years ago

(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

comment:22 @Denis-de-Bernardy6 years ago

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-Bernardy6 years ago

make the domain explicit, to simplify their extraction by nikolayb

comment:23 @Denis-de-Bernardy6 years ago

there you go.

@Denis-de-Bernardy6 years ago

per discussion on IRC

comment:24 @Denis-de-Bernardy6 years ago

[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

comment:25 @Denis-de-Bernardy6 years ago

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"

comment:26 @Denis-de-Bernardy6 years ago

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

@nbachiyski6 years ago

Use continents-cities domain

@Denis-de-Bernardy6 years ago

same as previous patch, with cities list

comment:27 @ryan6 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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

comment:28 follow-up: @xibe6 years ago

  • Keywords 2nd-opinion removed

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)

comment:29 @Denis-de-Bernardy6 years ago

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.

comment:30 in reply to: ↑ 28 ; follow-up: @nbachiyski6 years ago

Replying to xibe:

Thanks a lot to all those involved!

Now, a few details before parting our separate ways:

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.

comment:31 in reply to: ↑ 30 @xibe6 years ago

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!

comment:32 @demetris6 years ago

Thanks for taking care of this, Denis and Ryan!

Note: See TracTickets for help on using tickets.