Re: create compendium automatically

["Fco. Javier F. Serrador" <franciscojavier fernandez serrador hispalinux es>]

I think that the actual infraestructure cannot be suitable for that
matter, so I began creating specialiced compendia. I have one general
compendia with common strings (File, Edit, Cut, pate and the like) and
others more specific (mail compendia, browser compendia, etc).

An additional effort should be done to support TMX, so compendia
interchange could be done among different databases.

Bye

El dom, 28-09-2003 a las 23:31, Danilo Segan escribió:
> недељa, 28. септембар 2003. 22:12:21 CEST — Keld Jørn Simonsen написа:
> > I think the compendia are a good idea, but it seems like we need to  
> > do some
> > optimization on the code, eg by employing database techniques.
> 
> Yes, of course it's probably possible to do it, but it would involve  
> rewriting of a lot of standard gettext tools to be more suitable for  
> the task (or writing the same tools from scratch, with different  
> objectives).
> 
> Quite similar approach could be taken in regard to status pages  
> optimizations, like caching the results of one msgmerge (which original  
> messages were fuzzied based on which previous translations), and  
> reusing this information in all other translations, and doing  
> incremental updates instead of rerunning msgmerge for each translation.
> 
> (For instance, we do a msgmerge on sv.po for gnumeric, and cache which  
> english messages are no longer present, and if there are some new  
> english messages, from what was a fuzzy match gotten [which english  
> string]; then, we just do the same job for sr.po, without searching all  
> the stuff, and all the messages that were not present in sv.po but are  
> in sr.po are checked in the same way and added to database if they were  
> fuzzied.)
> 
> Yet, there are big flaws to any of these approaches: dedication of time  
> and resources to accomplish them is quite big, at least at the start.  
> At the moment, I think it would be far better to dedicate any developer  
> time we've got left to creating tools for DocBook-to-PO transformation  
> tools. Of course, my priorities might be skewed, so I hope someone will  
> give another point of view soon, with all the reasoning behind it.
> 
> 
> Cheers,
> Danilo
> _______________________________________________
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> http://lists.gnome.org/mailman/listinfo/gnome-i18n