On Monday 14 July 2008, Andreas Schamberger wrote: > I'm quite busy at the moment but I took the time today to write a quick > requirements document for a ezlupdate.php script. > > Most of the required functionality is already in the script I posted > some time ago. Therefore it shouldn't be too much work to add the rest.
Thanks a lot for the effort! It would be great to get rid of the Qt/X11 dependency for ezlupdate. My comments as a translator and ezlupdate developer: The req. doc talks about translatable strings in templates, but such strings can also be placed in PHP files (there are many in the current kernel). This must be supported. Support for the Qt Linguist translator program must be kept, but that's a non- issue since the XML format is already given. I second Björn in that it would be nice to have a web interface for it too, where one can create/update translation files, download them to edit with the linguist or other programs, and then upload them again. But this is secondary, I think a command line script that replicates and improves the current ezlupdate functionality is most important. The current ezlupdate scans either the kernel and main templates, or a given extension. I'd like an option to scan everything at once. We currently have a problem with extensions. If you look at ezodf or ezflow for example, you will see that they contain templates that have been copied from the main design, with a few edits. They still contain lots of strings that have not been changed from the original templates, with some new strings added. ezlupdate doesn't understand this, it adds everything to the extensions translation file, which means that the translators end up translating the same strings several times. I think the new ezlupdate, when scanning extensions, should look at the context to determine if a given string is from main/kernel or from the extension. If it begins with design, kernel or lib, we know it is from main, and should be ignored. Also, if it begins with "extension/[anotherextension]" it can also be ignored. For this to be safe, it also has to consider extensions when scanning the main design. In this case, it has to add strings to the main translation file, even though the templates are in an extension, if the context begins with design, kernel or lib. This means, of course, that developers have to use context strings correctly, or translations will end up in unexpected places. Opinions? -- Gunnstein Lye Systems engineer [EMAIL PROTECTED] | eZ Systems | http://ez.no -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
