Hi Janez,
Janez Pirc wrote:
I see the propposed solution by Michael usable only if there'll be enough effort to clear the meaning of every ID of a message so that a translator would know what he is actually translating.
Therefore the English translation (en_GB) is so much important because it is the reference implementation including the comments.
And it would of course also be necessary to avoid the problem mentioned by Michael with the openca.pot, that was missing quite some messages or errors needed to be translated. Not to mention that some words or sentences are written in the config files, and so not even translatable.
Therefore we think about a database based solution in the second phase. If you have a database then an administrator can add new translations (e.g. for special fields) dynamically. If the admin backups the database then he backups the translations too.
So one major question would be where should we start. I think the easiest stuff are the modules because they are really good isolated from the rest and they cause the most trouble (during the string extraction).
Michael -- _______________________________________________________________
Michael Bell Humboldt-Universitaet zu Berlin
Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 [EMAIL PROTECTED] D-10099 Berlin _______________________________________________________________
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
OpenCA-Devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openca-devel
