On Thursday 24 July 2008, Andreas Schamberger wrote: > Gunnstein Lye schrieb: > > 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. > > As the title of the requirements document says I want to build a tool > for the TemplateTranslationTiein and therefore for extracting from > templates and not for extracting strings from PHP code. > This script will be part of the TemplateTranslationTiein to have the > right dependencies. > > What you also want would be another script coming with the Translation > component for extracting translation function calls in PHP code. > > As most of the code after the string extraction should be equal this > common code could be added to the normal Translation component: > - update existing language files with newly added strings > - create a new translation file for a new target language from another > file > > This is also the part that needs to be written to finish the script I've > done.
Agreed. From a user perspective it's bad to have two scripts in ezp for this, but we could of course make a wrapper around the two. > > The current ezlupdate scans either the kernel and main templates, or a > > given extension. I'd like an option to scan everything at once. > > As far as I know this is not possible as you would build a script that > has dependencies on other components. A job for the wrapper script then. > > We currently have a problem with extensions. If you look at ezodf or > > ezflow > > [...] > > This is all ezPublish specific and I don't really have a clue about > that. But I don't think this is exactly a problem of extracting and > updating the strings but a problem of a proper translation process and > tooling afterwards as it is very application specific. What hinders you > to pass it through some postprocessing tool afterwards that solves these > problems? I work only with ezp, so that's my angle... if the concept of extensions exists in ezc, then we should consider this problem. If not, forget it and let ezp do some post processing. -- Gunnstein Lye Systems engineer [EMAIL PROTECTED] | eZ Systems | http://ez.no -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
