[development] translation for the installer?
gerhard at killesreiter.de
Fri Jul 14 15:59:25 UTC 2006
Stefan Nagtegaal wrote:
> Op 14-jul-2006, om 15:45 heeft Gabor Hojtsy het volgende geschreven:
>> 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
>> (This is a development issue, not a translation one, this is why I
>> brought it up here).
> 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:
> $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.
More information about the development