On Wed, Aug 24, 2005 at 08:21:14PM +0200, Martin Quinson wrote: > Imagine now that for a reason X or Y, a new version of the package comes out > with an updated translation in language xx. Unfortunately, the xx team also > had a translation in the DB, much improved of course. If the maintainer does this then either: - he did not receive the updated po from the i18n team but received an update or bug from someone else - he received two updates and decided that the one that did not belong to the i18n team was best - he updated the template (pot) and this made the previous translation obsolete or he manually updated the translatios himself (e.g. the update was a reference to a file named that now is named differently, even if he cannot speak the language of the po file he can still pinpoint the location of the filename, update that and unfuzzy the entries) - he mixed things up (maybe used a different language for that po file) I guess that yes, the central DB should pin-point these issues. You are right, they are uncommon but sometimes happen. It might be too much to analyse them on a msgid basis. Maybe it could just take the latest .pot file from the package, msgmerge it with the po file of the database and compare it with the po file in the package. If they differ, then manual intervention is necessary. > No, the script needs to pinpoint the parts on which there is really a > conflict, an warn the translator about it so that a human can deal with the > problem without having to check everything manually. Exactly what the > proposed algorithm tries to do. I guess I should have given some more > context from the begining on, sorry. With this context that algorithm might make sense. I don't really parse it properly (I guess you mean 'changed' when you say 'improved') so I can't discuss about it throughly. I guess I rather see it in action and see how it works for some (un)common situations :-) Regards Javier
Attachment:
signature.asc
Description: Digital signature