Langauge configuration is one of the strangest beasts in Drupal. We tell everybody you should not use t() on dynamic data, but the language system freely uses t($language->name) as it wishes. Woah! To make that kind of work, it specifically asks for the English name of the language, to mimic how t()-ed strings work. (The basis for using t() is that *most* languages will use a predefined name so they in some way come from code after all even though they are user configurable). Also, even worse is that languages ask for a native name too, which is basically a "cache" of t($language->name, array(), array('langcode' => $language->language). So we ask for the language name in two specific languages on one form!
You see this pattern nowhere else in Drupal. If you go to edit a contact form or a view, the title for the contact form/view will be asked in *your* admin language (and then translated from there by i18n_string). There is absolutely no reason for the language list to be exceptional here. People are repeatedly puzzled about why we ask for the English name and a native name for a language. Many sites who use this functionality don't even have any English support on the site, but they need to specify the language in English anyway. Scandal!
To clean this up, we should stop pretending we have a configuration translation system. We don't have one. We should lead by example and stop t()-ing user editable data (language name), ask for the language name simply in the configuration language and stop asking the user about the native name, which is to be retrieved from the translation system itself anyway.
We have a couple of patches ongoing that I'd prefer to not break, so marking this postponed on them:
- #1260860: Rework language list admin user interface
- #1280530: Decouple domain/path negotiation setup from language configuration
- #1296566: Improve usability of add language screen
Comments
Comment #1
Gábor HojtsyHere is a quick patch to show how this "feels". No update function but one will need to be provided. Once this and #1280530: Decouple domain/path negotiation setup from language configuration lands, the language edit/add form is going to be *very* simple, like this:
Comment #2
Gábor HojtsyInterested in test results.
Comment #4
plachComment #5
Gábor HojtsyShould fix the tests.
Comment #6
Gábor HojtsyEven more t()-ed language name instances found. I believe this is (almost) complete. Did a pretty extensive search/hunt. :)
Comment #7
Gábor Hojtsy#1280530: Decouple domain/path negotiation setup from language configuration did land and made most of this fail when applied. Here is a reroll.
Comment #8
Gábor HojtsyRerolled for latest core changes.
Comment #9
tobiasbYou mean that Deutsch is Deutsch not German in e.g. the english interface?
Comment #10
Gábor Hojtsy@tobiasb: this patch attempts to solve two configuration translation related problems:
A: $language->name which is user input is used in t() to be translated. This is a bad practice we fight against extensively in contrib and elsewhere in core. User input should never be t()-ed. The argument for that was that language names are usually from a preset list. Well, that is not a good argument for this. We should not t() user editable data period :)
B: $language->native is just a "cached" value of $language->name translated to the language in question, and we do get that data via the translation system itself, so there is no reason to bother the user with entering it, so we both simplify the interface and the data structure. Whatever we can do on behalf of humans in our code, we should do instead of relying on humans do it :)
Did this help provide background?
Comment #11
Gábor HojtsyRerolled for recent changes, no changes. Please, please review!
Comment #12
plachThe patch looks good and seems to work well from a cursory test. There are still a couple of things to be fixed:
I guess this should be
locale_update_8000()
.Probabiy we need to remove native language names from the predefined list and fix _locale_prepare_predefined_list (see line 815).
-20 days to next Drupal core point release.
Comment #13
Gábor HojtsyFixed patch with 8000 number for the update function, you are right. On the native name removal from the built-in language codes, we are in fact doing the contrary. See #1295696: Sync predefined list of languages with localize.drupal.org and extend native language information, where I extend the list to have native names for all. Basically, we need to display native names for languages from where we don't yet have translations loaded (unlike the case for names here, where if we do need the translation, we should have it loaded, since we specifically have it configured). Any other concerns?
Comment #14
catchLooks like this needs an @ingroup. edit, or @addtogroup, I can never get these right.
Comment #15
plachOk for the predefined list but:
Comment #16
Gábor Hojtsy@plach: the list of predefined languages comes from the source code and the source code parsed in potx() extracts those strings. Thus they should be available for translation like any other t()-ed string. Its not direct, its indirect like hook_menu() strings, but its there.
@catch: its defgroup is both block.install and system.install in D8, so I've added that here too.
Any other issues?
Comment #17
plachLooks good!
Comment #18
Gábor HojtsyAll right, @catch unearthed our phpdoc grouping doc at http://drupal.org/node/1354#groups. It says @defgroup updates-7.x-to-8.x should only be used once in the whole codebase in the most important place. I've verifier this with 7.x update files. So we should use addtogroup elsewhere. The attached patch uses that for locale.install (and fixes the only one other place, in block.install too). I expect this to land soon, so including that slightly related piece seemed like a good idea.
No other changes, so if passes tests (it should :), should be back on RTBC.
Comment #19
plachComment #20
catchSorry to nitpick but the addtogroup isn't quite right, according to block.install D7, we only need:
since the description is already in the original defgroup.
Comment #21
Gábor HojtsyThere you go. (No other change).
Comment #22
catchCommitted and pushed to 8.x, thanks!
Also
15 files changed, 50 insertions(+), 94 deletions(-)
mmm diffstat.
Comment #23
podaroknice.
tnx!
Comment #24
Gábor HojtsyAdded change entry http://drupal.org/node/1323146 for this. Thanks!
Comment #26
sunCleaning up bogus/duplicate "API cleanup" term.
Comment #27
Gábor HojtsyTagging for base language system.
Comment #28
Gábor HojtsyTag for config translation too).