Drupal 5 installation language files
Hello list, the new Drupal 5 web installer also provides a way to select the language for the installation before doing anything like database setup. I'm wondering if Drupal 5 ships with translated installation or if that's just an interface for custom distributions. Should we include installation translations? If so, we should call for translations once the string freeze is in effect. Konstantin Käfer – http://kkaefer.com/
Hi, On Fri, 17 Nov 2006, [ISO-8859-1] Konstantin K�fer wrote:
the new Drupal 5 web installer also provides a way to select the language for the installation before doing anything like database setup. I'm wondering if Drupal 5 ships with translated installation or if that's just an interface for custom distributions.
Should we include installation translations? If so, we should call for translations once the string freeze is in effect.
I don't think Drupal is supposed to get shipped with installer translations. The matter of fact is that users will expect Drupal to work in the language used in install time. There is not yet a solution for this to work nicely (ie. create the language an import the whole big translation in install time). I intended to code something for this, but it was very late in the release cycle, and feature freeze broke in. So for now, as far as I see, people will be able to download Drupal 5 and the translation, copy the installer.po file to the relevant folder, and enjoy installing in their native language. Then import their PO file the usual way. We can experiment with providing translations as install profiles (without Drupal core itself, only a profile file and a simple module to do the auto installation of the translation). That would (migth) simplify initial interface translation. Gabor
It would be really cool if the drupal.org packaging script could detect all available translations for core, and then make a different package of the latest version of Drupal for all supported languages. Then users could just download e.g. Drupal 5.1: Portuguese version; and right from the first install screen, the whole thing would be in their native language. Of course, I have no idea how hard this would be to set up (got any free time, dww? :P). I'm just saying that this is probably the kind of thing we should be aiming towards. Jaza. On 11/18/06, Konstantin Käfer <kkaefer@gmail.com> wrote:
Hello list,
the new Drupal 5 web installer also provides a way to select the language for the installation before doing anything like database setup. I'm wondering if Drupal 5 ships with translated installation or if that's just an interface for custom distributions.
Should we include installation translations? If so, we should call for translations once the string freeze is in effect.
Konstantin Käfer – http://kkaefer.com/
How about making url rewrite convert URLs of <lang>/install.php over to install.php?lang=<lang> or something like that? That shouldn't take terribly long to do and it might be possible to slip through before the RC! -- Sammy Spets Synerger Pty Ltd http://synerger.com On 18-Nov-06 12:03, Jeremy Epstein wrote:
It would be really cool if the drupal.org packaging script could detect all available translations for core, and then make a different package of the latest version of Drupal for all supported languages. Then users could just download e.g. Drupal 5.1: Portuguese version; and right from the first install screen, the whole thing would be in their native language.
Of course, I have no idea how hard this would be to set up (got any free time, dww? :P). I'm just saying that this is probably the kind of thing we should be aiming towards.
Jaza.
On 11/18/06, Konstantin K?fer <kkaefer@gmail.com> wrote:
Hello list,
the new Drupal 5 web installer also provides a way to select the language for the installation before doing anything like database setup. I'm wondering if Drupal 5 ships with translated installation or if that's just an interface for custom distributions.
Should we include installation translations? If so, we should call for translations once the string freeze is in effect.
Konstantin K?fer ? http://kkaefer.com/
How about making url rewrite convert URLs of <lang>/install.php over to install.php?lang=<lang> or something like that? That shouldn't take terribly long to do and it might be possible to slip through before the RC!
The installer localization is already in core and it works. I have a translated install.po file (German). Just drop it in profiles/default as "de.po" and you'll be able to select the language when you go to / install.php in your browser. Konstantin Käfer – http://kkaefer.com/
On Nov 18, 2006, at 2:02 AM, Konstantin Käfer wrote:
The installer localization is already in core and it works. I have a translated install.po file (German). Just drop it in profiles/ default as "de.po" and you'll be able to select the language when you go to /install.php in your browser.
"install.po"? goba had me special case "installer.po" here: http://drupal.org/node/93121 "Do not merge installer.po into merged PO file" when the packaging script is creating tarballs for translations, it normally merges all the .po files into a giant [lang].po file. however, it's now excluding "installer.po" so you'd end up with: installer.po # just the installer strings de.po # everything else in your de-5.x-1.0.tar.gz file. if you call it "install.po", it'll get merged in with de.po. do we need to change the behavior of the packaging script of the translators? ;) thanks, -derek
On Nov 18, 2006, at 2:13 AM, Derek Wright wrote:
do we need to change the behavior of the packaging script of the translators? ;)
uhh, that should be: "do we need to change the behavior of the packaging script *OR* the translators?" ;) -derek
Hi, btw. where can i find translation files for Drupal Installer? Is there a handbook? I would like to start a translation for Czech language. -- Jakub Suchy http://www.drupal.cz
On Sat, 18 Nov 2006, Jakub Suchy wrote:
btw. where can i find translation files for Drupal Installer? Is there a handbook? I would like to start a translation for Czech language.
http://drupal.org/drupal-5.0-beta1#what-about-5-translations BTW there is a translators mailing list, join there if you are interested. http://lists.drupal.org/listinfo/translations Gabor
"install.po"? goba had me special case "installer.po" here:
I don't remember how it's been called but I generated a file with extractor.php that just contains the install messages. For Drupal to be able to find the correct language file, the file has to be named like the language (e.g. de.po or fr.po). Konstantin Käfer – http://kkaefer.com/
Konstantin Käfer wrote:
"install.po"? goba had me special case "installer.po" here:
An idea: Let's include very short translation of first installator page in every language (5 sentences in 250 languages is not much, especially in tar.gz). The user will have a choice to select a language (or the language will be browser detected) and then the installator will download selected language file for installation (or complete Drupal .po files). This way we won't have to include all translations in every distribution and still the user will have translated installation (and hopefully whole Drupal) Does it make sense or is it already implemented? :) Jakub
Hi,
Does it make sense or is it already implemented? :)
It does make sense. And a part of it is already implemented (installer translation). I also thought about a similar system. It's a little bit more than 5 sentences for installer.po (de.po is about 9kB). The installer workflow could be: * "This is Drupal installation. Please select a language do continue" * If the user selects a language other than english, one of the following will happen: * If the required files are already in place (e.g. localized releases, like drupal-5.0-de.tar.gz), they are used to continue * Otherwise, the required files (both installer translation and the whole language file) are downloaded from the distribution's Project home (e.g. drupal.org) * Installation continues in the selected language * If a language other than english is selected, locale.module is activated and the translation imported and set as default That's definitely not for 5.0, though. Konstantin Käfer – http://kkaefer.com/
On Sat, 18 Nov 2006, [ISO-8859-1] Konstantin Käfer wrote:
* "This is Drupal installation. Please select a language do continue"
This already works as you know for sure.
* If the user selects a language other than english, one of the following will happen: * If the required files are already in place (e.g. localized releases, like drupal-5.0-de.tar.gz), they are used to continue * Otherwise, the required files (both installer translation and the whole language file) are downloaded from the distribution's Project home (e.g. drupal.org) * Installation continues in the selected language * If a language other than english is selected, locale.module is activated and the translation imported and set as default
The locale module is already enabled if you install Drupal 5.0 using a non-English interface. The only missing piece is translation import for the actual Drupal interface. The proposal you have above is faulty in several points (for example there is no ungzip functionality in Drupal built in, and there will be no such feature in the foreseeable feature IMHO). Module translation imports should be done around the same lines as module database table creations go. Why import aggregator module translations if I am not going to use it? Now we don't have the tables, but will still have the translations imported. So the first point to look into is putting the PO files into the module folders per module (as the info, install and other files are there). If you install (turn on) a module and have locale module turned on, you should get all the language files imported for that particular module for all enables languages automatically without further interaction. This should work first from the file system with per-module PO files. It is possible to package the PO files so that they have the modules folder structure, so if you unzip them into the Drupal folder, the PO files fall into their proper place (including the installer translation file). Since PO files are generated per source file (with common strings aggregated into general.po), it is possible to move the PO files to the folder where they belong in the source. It is also possible to write a module to automatically import the initial PO files for the modules you have in your install profile, so that you can start working with Drupal in the exact language you used to set up the system. It is possible to extend this module to watch when a module is enabled to import the module translations from the database.
That's definitely not for 5.0, though.
The above was the grand plan for 5.0. Fortunately given how possible it is to bend Drupal, it is doable to experiment with the above as an install profile or contrib module. It is also possible to ship translations as install profiles (without Drupal core files), so you can dump them onto Drupal, and enjoy fully localized install and usage. Just someone needs to find the time, step up and code all this. I would say go for locale file based imports first, since unless it is done, there is no point in dreaming about remote file download and translation import on the fly. Gabor
Hi, you make good points, Gabor.
for example there is no ungzip functionality in Drupal built in, and there will be no such feature in the foreseeable feature IMHO I think that could be solved. phpMyAdmin is using GZip as well and I had it on lots of different servers and none of them didn't allow me to download/upload (g)zip files.
Module translation imports should be done around the same lines as module database table creations go. Why import aggregator module translations if I am not going to use it? Now we don't have the tables, but will still have the translations imported. So the first point to look into is putting the PO files into the module folders per module (as the info, install and other files are there). Correct. Since we split up the module's tables to their install files, we should do the same for language files. However, we need a good way of handling this without getting too complex. Currently, a downloaded translation is one big file. While this is good for importing it (you don't have to upload say 20 files), it's polluting the translation tables in the database.
It is possible to package the PO files so that they have the modules folder structure, so if you unzip them into the Drupal folder, the PO files fall into their proper place (including the installer translation file). This may work for certain configurations, but not for all. If you copy a folder "over" another, it will get replaced instead of merged on Mac OS X.
Konstantin Käfer – http://kkaefer.com/
On Sat, 18 Nov 2006, [ISO-8859-1] Konstantin Käfer wrote:
for example there is no ungzip functionality in Drupal built in, and there will be no such feature in the foreseeable feature IMHO I think that could be solved. phpMyAdmin is using GZip as well and I had it on lots of different servers and none of them didn't allow me to download/upload (g)zip files.
You mean exec()-ing gunzip?
Module translation imports should be done around the same lines as module database table creations go. Why import aggregator module translations if I am not going to use it? Now we don't have the tables, but will still have the translations imported. So the first point to look into is putting the PO files into the module folders per module (as the info, install and other files are there). Correct. Since we split up the module's tables to their install files, we should do the same for language files. However, we need a good way of handling this without getting too complex. Currently, a downloaded translation is one big file. While this is good for importing it (you don't have to upload say 20 files), it's polluting the translation tables in the database.
The translation files are already split up to ease the translators work. They are split up in a way that is easy to put into folders. Just the proper folder need to be found out for each PO file (and the packaging script should not merge the files).
It is possible to package the PO files so that they have the modules folder structure, so if you unzip them into the Drupal folder, the PO files fall into their proper place (including the installer translation file). This may work for certain configurations, but not for all. If you copy a folder "over" another, it will get replaced instead of merged on Mac OS X.
There should be an option to not replace the folder (unfortunately I have no day-to-day experience with macs).
Am 18.11.2006 um 18:45 schrieb Gabor Hojtsy:
You mean exec()-ing gunzip?
No, http://php.net/manual/en/ref.zlib.php
The translation files are already split up to ease the translators work. They are split up in a way that is easy to put into folders. Just the proper folder need to be found out for each PO file (and the packaging script should not merge the files).
I know, I'm a translator.
There should be an option to not replace the folder (unfortunately I have no day-to-day experience with macs).
I'd be glad if you'd share the trick (without using Terminal). Konstantin Käfer – http://kkaefer.com/
On Sat, 18 Nov 2006, [ISO-8859-1] Konstantin Käfer wrote:
Am 18.11.2006 um 18:45 schrieb Gabor Hojtsy:
You mean exec()-ing gunzip?
Ah, ok. Quoting from that page: "Zlib support in PHP is not enabled by default. You will need to configure PHP --with-zlib[=DIR]". This basically rules this out, since seamless zip handling is not possible with out of the box PHP.
There should be an option to not replace the folder (unfortunately I have no day-to-day experience with macs).
I'd be glad if you'd share the trick (without using Terminal).
If only I would know. Unless someone throws a Mac my way, you need to turn to someone else (who actually has a Mac :). Gabor
Ah, ok. Quoting from that page: "Zlib support in PHP is not enabled by default. You will need to configure PHP --with-zlib[=DIR]". This basically rules this out, since seamless zip handling is not possible with out of the box PHP.
It's not enabled by default, that's true. But neither is GD or ImageMagick: "You will need to compile PHP with the GD library of image functions for this to work. [...] To enable GD-support configure PHP --with-gd[=DIR], where DIR is the GD base install directory." We could enable downloading if zlib is there (which it is on probably 95% of all production sites). Otherwise, the user has to do it manually (links are shown during installation) or download an uncompressed version (about 500 kB for a complete 4.7 translation). I think that's a fair compromise. Konstantin Käfer – http://kkaefer.com/
participants (6)
-
Derek Wright -
Gabor Hojtsy -
Jakub Suchy -
Jeremy Epstein -
Konstantin Käfer -
Sammy Spets