| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | user interface text |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | D8MI, language-ui |
Issue Summary
It has happened a few times to me now, that I clicked my way through the admin system to add a language to a multilanguage site, and then started thinking about importing the translations after adding the language.
...that's the line of thought that automatically develops in my head. However, it gets you in trouble with language packs that have lots of small .po files. (You will need to delete the language & hope you've added no manual translations in the meantime, then extract the language pack and add the language again.)
There are some remarks on this in /admin/settings/language and /admin/build/translate/import (which are kind of fuzzy IMHO), but I think the place to clearly 'warn' people that they should extract their language packs is /admin/settings/language/add -- right above the 'add language' button. Not anywhere else.
The 'patch' adds a paragraph on that. Note I wasn't sure about how strong I should make the warning... I used language similar to the other places.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| locale_addlng-msg.diff | 2.73 KB | Idle | Failed: Failed to apply patch. | View details | Re-test |
Comments
#1
That's a pretty good addition.
A couple of notes:
- This will need to be a patch for 7, as the strings for 6 are frozen in place except for error corrections.
- To the extent it is reasonable, we tend to avoid the use of "Drupal" and "Drupal's" in strings, in case someone is using re-branding it for some reason.
- If this patch is for 7, it needs to follow 7's string concatenation rules; namely, spaces on both sides of concatenation operators.
#2
Done.
#3
The last submitted patch failed testing.
#4
Reroll (I haven't looked at D7 in ages, sorry)
#5
oops, forgot status
#6
hey, i was just trying to review this, but A) can't find the page in D7 cause the path has changed, though i suspect it's now /admin/config/regional/translate/import B) if that is the page, the text seems to have changed, and so the patch doesn't apply anymore, and C) if the patch can be applied, needs the 80 char word wrap (which i was going to add, but then realized the patch probably doesn't apply anymore!)
if you can drop the URL of the proper admin page, i'll come re-review
#7
Hi,
The URL is admin/config/regional/language/add (after enabling locale.module). (This was admin/settings/language/add in D6)
The patch still applies, and adds a second (smaller) paragraph to that page.
I didn't change anything to /admin/config/regional/translate/import. The language on that page (which was admin/build/translate/import in D6, and which is still the same) is now arguably duplicate with the extra paragraph I added to admin/config/regional/language/add...
but I think it has its use on both pages. Anyway my argument for the patch was that it really does have use in the new location (as a kind of 'warning' before adding a language.)
#8
Needs work: needs to be a git patch now and I think this can be done using fewer words.
#9
Just learned that #1191488: META: Integrate l10n_update functionality in core would make this not needed at all or at least need very different wording. Postponing it for a bit.
#10
Tag…
#11
Sorry, quickly discussed this with Gabor, lets not postpone…
#12
I'd actually very much prefer if we can refere to l10n_update module. It might be a precedent to suggest a contrib module, but setting up a foreign language site without l10n_update is a royal pain now. You need to download, import, etc. .po files for all your modules in all your languages and you need to keep them up to date as they are updated. The issue @yoroy linked to is about including it in Drupal 8, that is not going to happen for Drupal 7 though. The best thing we can do here is to suggest people use that, or we risk they going down on a big hole of pain.
#13
+1 for not referring to .po files anymore. Really everyone's workflow has already moved away from using .po files. With good reason.
But wait. The original reason for this issue was that "first adding language, then adding .po files" was painful. (Those 2 steps should be done in reverse order, to update translations with the click of a button - instead of 100 clicks.)
This isn't true when using l10n_update anymore. Or with po files from localize.drupal.org, for that matter, since you can download one .po file for Drupal core instead of an archive containing 20+ files.
So - is this issue even valid anymore?
#14
Yes, it is still valid, l10n_update is not in core.
#15
Adding UI language translation tag.