Ain Vagula írta: > My comment: > Timar didnt mean that po-editors itself do something wrong (although > gettext itself can always surprise when merging), but there is some > functinality missing. Eg. in some editors you can maybe define, that > 'this is a tag and must be copied like it is when changed without > making string fuzzy'. From helpcontent fixes 90% (or more) are tag > fixes, which is really PITA for translator - to find out character by > character where is the change.
Exactly. I've just checked the free Open Language Tools (OLT) (https://open-language-tools.dev.java.net) and it at least highlights the tags in the PO file and does not let to edit them. For those who are interested I recommend to test this tool. I do not think that gettext merging tools will be ever able to handle tags and other placeables, because gettext was not designed for this. Probably a new workflow should be used to handle updates. That is: 1. Extract new and changed strings from the SDF file 2. Make a translation memory (TM) from the existing translated SDF file 3. Distribute new strings + the TM to translators who can work with OLT 4. Merge the new translations back to the SDF file This is what happened with this OOo 2.2 update in case of some Sun languages (e.g. i73150). Translators who use OLT should share their experiences in this list. The main question is how good the OLT is at ignoring tag changes. Does it offer good matches from the mini TM in case of tag changes? > Another pain for many languages is so called unique string principe > you count as benefit. Simple words, like format, group, start, etc. > have in original language one shape, are they nomens or verbs... In > target language we have to separate many such strings, as eg. 'format' > has in my language at least 5 different meanings. Now we use in > po-translation kde-style comments, that makes some additional work for > translators but can ensure at least reasonable quality. Unique string principle is a nightmare for Hungarian, too. I'm very happy that strings used for different purposes are in different lines in the SDF file. If OLT could handle SDF directly and if mini TM could store multiple translations for the same segment and if mini TM could store the context information of segments (i.e. the other fields of the SDF file), then you could forget about PO format and you could save a lot of trouble for yourselves. There are many ifs, but I don't thinks it is hard to reach these goals. The open standards (XLIFF, TMX etc.) - which OLT implements - allow these features. Andras --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
