Drupal cannot be installed in a non-predefined language

Do we really want to prevent people from installing Drupal in a language that isn't on our predefined list? That doesn't seem right to me. I'm moving this to the "language system" queue for now, to get some more opinions on that. (I do think it might be better if we did some validation of the file itself instead.)

The patch also has some code style issues; please see http://drupal.org/coding-standards. Thanks!

Related issues:

#988262: Could not complete installation in French
#994500: Drupal should not require .po file rename in installation

Quoting a discussion between me and Gábor:

@Gábor Hojtsy:
Do you think it is possible to have a more user-friendly failure here?

@plach: Yes, the docs were introduced with #882164: Adding a language help page during installation is incorrect and I said there that it would indeed be best to modify the pattern handler instead to import files with arbitrary prefixes and still identify the proper language. It is definitely possible, but there was not much support for that. Support and help is welcome to make it work better :)

@Gábor Hojtsy:
I guess it's too late for introducing a simple error message saying the file pattern is not recognized, right?

@plach:
I still think we should fix the behavior (it will not go against string freeze :), but people were strong to document how it works instead. We should just fix how it works. Drupal elsewhere will recognize anythingyouwant.$langcode.po just not in the install profile, really. The fact this made a bit harder in the installer is that it send around the filename as the translation language code, so we'd need to pass both names around somehow.

I think the names are mixed up in the quoted discussion (actually, in the exact opposite :).

Also, I think the patch is going in a bad direction. We should not exclude languages which we don't have predefined from being installed with. We should make assumptions (set the name to the same as language code maybe?, set direction to LTR and set native name also to language code). I tried and reproduced this issue with a simple hk.po file in my standard profile translations BTW.

Providing a IMHO great patch at #994500: Drupal should not require .po file rename in installation for the long file name problem and retitling this to be more accurate.

subscribe

Ok, so here is my suggested patch. Modifying how locale_add_language() works would constitute an API change IMHO, so instead I added a predefined language check in the installer and prefilled "dummy" (AKA the best we know) values for the language. Also fixed empty string, boolean, etc type matches in the invocation. To reproduce and test the bugfix:

- put in an empty hk.po in profiles/standard/translations
- pick "hk" in installation
- without patch it should break with the reported error (see issue starter)
- with patch, it should continue, even run a batch to import the (empty) .po file and once installed, the language list will have an item for it:

Issue summary

Drupal can be installed localized by putting .po files under install profile directories. The languages Drupal finds are offered for selection in the installer. Drupal has a list of predefined languages, but it also offers languages when a .po file was found but the language is unknown to Drupal. In this case, Drupal does not know about the full name, native name and direction of the language but it tries to add it as if those details were available. We need to fill in these details with some "dummy" information in this case to ensure adding a language fulfills the database constraints. This information can be edited later by administrators.

The impact of the bug is big because localize.drupal.org keeps adding new languages and when those are downloaded as .po files, those can be selected, but the installer fails with them and cannot complete.

Applied the patch and tested install:

- With Czech language - worked
- With empty hk.po - worked

The patch has code style issues and does not work with filenames longer than 12 chars. Working on it just now.

And here it is. Language code is truncated to 12 chars to fit into the {languages} table.

Additional test case covered: rename a valid .po file downloaded from l.d.o with a name longer than 12 chars: strings should be regularly imported.

No failure on my box.

#10: install-1007488-10.patch queued for re-testing.

That does not really work, since it will import regional variant translations as well. Think if you have pt.po pt-br.po, both will be imported with the new code if language code is pt, only first will be imported with the old code in the same situation (which is the right behavior). Same not just for language variants, but if a language code is prefix to another one (which is entirely possible since localize.drupal.org has some longer than 2 letter language codes due to no 2 letter code language keys assigned to certain languages). Eg. just added Tuvan with the language code "tyv", and there can very well be a language with the code "ty", although there is not one yet on localize.drupal.org.

I think we'd rather skip files with long language codes, they are not valid anyway. Just don't offer those on the UI. We already fixed the localize.drupal.org file download issue, so long language codes should really be very-very-very rare.

@Gábor Hojtsy:

I think we'd rather skip files with long language codes, they are not valid anyway. Just don't offer those on the UI. We already fixed the localize.drupal.org file download issue, so long language codes should really be very-very-very rare.

Ok, this works for me.

Implemented #14.

Hm. This really seems like it could still benefit from Gábor's final review.

Looks all good on a visual review as well.

Excellent, thanks.

Committed to HEAD!