Op 14-jul-2006, om 15:45 heeft Gabor Hojtsy het volgende geschreven:
Hi,
I looked through the installer code. It obvisouly does not even try to t() strings, since a database is not yet in place. My quite is how to tackle the issue of translating the installer to different languages.
- do not care about this, the installer is just a short process, only database setup, and then the profile can easily handle importing the translation and then on use that translation for install wizards
- load in the PO import code (locale.inc) and import a PO file for the installer if available into memory. the installer PO file should be small, so this should not be a resource problem.
- come up with some custom process of providing translations for the installer, like a simple key->value pair text file.
Since PO parsing is already done, translators are already familiar with PO editing and translation, the second option might be doable. We just need a simplified t() implementation for the installer, which works from the associative array loaded in by the PO import code.
It would be nice to provide a localized installer from the very start, and with the solutions proposed it would only need another file (installer.po) copied into the profiles folder before running the installer.
(This is a development issue, not a translation one, this is why I brought it up here).
Gabor
Well, I do have an opinion about that.. What I want for a long time is totally remove the generation/parsing of .po files from drupal.. It is a heavy process (I've heared that, so don't blaim me when I talk rubbish), and IMO a one time setup job you once do, and never touches again.. What I wanted todo is have another file in each module like eg. node. $language.translation, blog.$language.translation, etc, etc which does something like this: <?php $translation = array( 'node_menu_item_add_content' => 'add content', 'node_menu_local_task_' => 'edit', ... ); and then we could parse these files with the module which needs it. The biggest improvement (IMO) will be that homonyms (words with different meanings depending on the context/page they are displayed) will be easily solved (I think).. Goba, Idon''t know if you (dis)like this approach, but I just wanted to inform you about my head spinnings over a couple of years. i'm not a good programmer, and I am certainly not a drupalguru. I just hope you understand the reason behind this, and also do understand why I encourage some system like this. So please don't burn me down, but give it some serious thought.. Would/Could it be possible? Maybe even as a contrib-module? I think it would certainly speed up things, but I do not have any numbers.. Stefan