Locale support for the installer

This is how an installer.pot file looks now, unsuprisingly.

@Moshe: we are in talks with Jose on integrating some parts of i18n into core, and a language selector will be among these parts. We should be able to do it so that the installer can also make use of it.

Good idea Steven! Forked the t() extension suggestion into a new issue, and submitted a patch (with a slightly different prefix format).

Ontopic here is that we need a reliable way to extract strings used in the installer. If we can identify files in which all t() calls should be marked as used by the installer, then it is fine to get rid of st() altogether. Otherwise seeking st() calls in the Drupal source is the way now to spot installer messages which need to be extracted to a separate POT file.

After we forked this patch, and the t() changes got applied, here is another round with this patch. Reread #1, if you need to see the basic picture. The concept is still the same. The patch evolved a bit.

I changed _locale_import_one_string(), so that now it gets a clean $op parameter, and it received 'db-store', 'db-report' and 'mem-store', 'mem-report' operations. This way it can store strings in the DB or in the memory, and later storage stats (or in case of memory storage, the strings themselfs) can be queried. The lot of changed-looking lines in _locale_import_one_string() were not changed a bit, they were just indented 4 spaces further, to properly place them inside the switch() needed for the operations.

It still stands that I have stepped over the PO file selection problem for now. I would welcome suggestions on where should we look for the PO file, and whether we should present a language selection interface in the installer or not. What should we base such a selection on? Scanning for PO files in some folder? What folder?

This patch was tested with Drupal HEAD a few minutes ago, and both the installer and the site seems to work fine.

I also gave some more serious thought into file placement. There are several problems with shipping Drupal with installation translations. First I am sure most translations will not be ready on day one for the release. We would also always need a gatekeeper with core write access to commit translations.

Worse is that if you select a language for the installer, you expect the installed product to speak that language right? This is how it works in desktop systems and such... But we are definitely not going to ship with any complete language translation. They are really big. To put this into perspective, Drupal-4.7.3.tar.gz is 473.6 KB, and the hu-4.7.2.tar.gz (which is also valid for the 4.7.3 version) is 124.1 KB. One single complete translation is quarter the size of the whole core (both being compressed)!

What we can do in the installer is to search for a PO file for the installer and the same language PO file for the complete interface. People could download these in a package separately from Drupal core, and these would extract nicely into the Drupal core directory tree. The installer could use the language found and could import the interface translation in that language at the end.

Interface (and installer) translations are bound to the install profile used, since the install wizard is provided by the profile, the modules turned on are set by the profile, etc. We could think about treating PO files as .css and .install files are treated now by core: create one PO file for the default turned on modules and spread module specific PO files as module specific .css and .install files are spread among modules. Then if users enable that module, the PO file would import automatically.

Ps. we could support setting up of multiple languages in install time, but importing more then one language will surely time out PHP (the above Hungarian translation unzipped is half a megabyte, and it all needs to be read in and parsed by Drupal).

Opinions?

Here comes a (hopefully) core ready version, with a locale selection as requested. Works this way:

• You first select the profile to use (or the only one is autoselected for you).
• The system 'greps' for all .po files for that profile, if more then one is available, you get the options to choose.
• The locale you have choosen if used to present the installer UI. Later on the locale module is also enabled by default, if any locale was available (either used or not) during install time.

This patch continues on the assumption that Drupal is not going to get shipped with any installer PO files. You download your language pack, and it is going to have this new folder structure in it, having profiles/default/it.po (or an Italian translation) in it for example. You unzip that into the Drupal folder before installing. Once you start the installer, it will automatically be Italian if you only have this locale or will offer all available languages if you have more locales there.

I would really appreciate reviews of this patch, so we can get this into the next Drupal version. Automatic OI import on module installs can be easily done later (without core modification if we would not be able to make it with that feature). But without this patch, people will not be able to start off their install process in their own language.

I have tested this patch locally with some dummy translations (which give nice error messages because of being malformed PO files), and a small Hungarian sample translation. It works.

Here comes an updated POT file, so you can test with it (add in some sample translations, name it something like de.po and put it into the profiles/default folder).

Updated patch, which supports selection of the built in English locale too. Screenshot coming.

Here are two shots showing the locale selection (which shows the locales available for the profile) and the database setup screen after selecting the Hungarian locale.

It was worded after 'Select your installation profile' which is the exact title displayed if you have one or more profiles to choose from. I am open for better ideas :)

Patch wording fixed as Stefan requested. Also fixed a small glitch in locale name printing, plus made English less of a special case (nicer code). Tested it and it works fine. I feel this is RTBC.

Tested the patch more deeply. Fixed the issue of $locale colliding with the bootstrapped Drupal $locale global (needed to rename the installer one to $install_locale), plus made the successful install page t()-able.

Screenshots of the installer: 1. language selection, 2. chmod error in Hungarian, 3. successful installation messages (with chmod warning)

Jose, the locale module is already enabled by this patch in case you have any language additionaly to English for the installer. The modules to import their .po files in their _install() hooks is the next step, and is a subject of another issue.

In the meantime, get_t() was introduced (by Steven?) to do exactly what I have done in a ternary operator here. So use get_t() instead. A oneliner.