[development] translation for the installer?

[Stefan Nagtegaal]

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