[development] translation for the installer?
Drupal-Devel at iStyledThis.nl
Fri Jul 14 15:31:04 UTC 2006
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
> - 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
> 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
> 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).
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:
$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
More information about the development