[development] translation for the installer?

[Gerhard Killesreiter]

Stefan Nagtegaal wrote:
> 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.

This sounds like a feasible solution.

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


First of all this is totally unrelated to the topic that Goba posted 
about, namely translation of the installer's interface.

Second, a lot of people - including Goba and myself - worked hard to get 
the PO stuff into core.

Third, the reason for this was that translation through PO files is a 
well established process in the OS community and thus we have been able 
to get more translations than before.


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


The only serious problem with homonyms that I am aware of is that the 
English abbreviatation for May is equal to the non-abbreviated version. 
I know this to be a problem for the Spanish translators, I am not sure 
it exists for other languages or other English terms.

I am unfortunately unaware of a non-hackish solution to the May problem, 
but it certainly does not warrant to complicate the translation process 
in the way you propose it.

Cheers,
	Gerhard