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).