Re: [l10n-dev] followup to issue 73501
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]
Re: [l10n-dev] followup to issue 73501
Andras Timar napisał(a): 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? Yes, it does, but Transolution (a Python XLIFF translation memory tool) was even nicer as it allowed many ways to visualize tags on the screen (so that the view is not cluttered). You could try MemoQ (freeware and Hungarian, made by engineers from Morfologic, which is a great recommendation to me), and Across (from Nero). They are closed source but still free to use (MemoQ is even Linux-compatible, I guess). And there's OmegaT - tag handling is probably better now than before. I like OLT as I was able to do some translation jobs that would require the notorious TagEditor from Trados, yet it is very slowly developing as the main developer from Sun, Tim Foster, is not working on that anymore. I could try to implement new features but... It's not high on my to-do list. Just my 2 cents, Marcin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] followup to issue 73501
On 18 janv. 07, at 03:40, Marcin Miłkowski wrote: Andras Timar napisał(a): 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? Yes, it does, but Transolution (a Python XLIFF translation memory tool) was even nicer as it allowed many ways to visualize tags on the screen (so that the view is not cluttered). You could try MemoQ (freeware and Hungarian, made by engineers from Morfologic, which is a great recommendation to me), and Across (from Nero). They are closed source but still free to use (MemoQ is even Linux-compatible, I guess). And there's OmegaT - tag handling is probably better now than before. It depends on what you mean by before. The main improvement is that OmegaT TMX files now respect tags and encapsulate them in the proper XML code. We have tested import of OmegaT's TMX into SDLX or Trados etc and the results were quite positive. Besides for that OmegaT does not use penalties for different tags in match and source, so in a way it is nicer on the user. Plus it is slightly more intuitive and faster than OLT (that I use also sometimes). But since OmegaT is not a XLIFF editor, it requires to work on the source file directly, and thus to have the source file format supported (PO is one of the supported formats). I like OLT as I was able to do some translation jobs that would require the notorious TagEditor from Trados, yet it is very slowly developing as the main developer from Sun, Tim Foster, is not working on that anymore. I could try to implement new features but... It's not high on my to-do list. Jean-Christophe Helary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] followup to issue 73501
I'll bring this conversation out of IZ. Clytie wrote: I also query the utility of this type of string: \image id=\img_id3146969\ src=\res/commandimagelist/sc_bezierinsert.png\ width= \0.222inch\ height=\0.222inch\\\alt id=\alt_id3146969\\Icon\/alt\\/image\ main0227.xhp#par_id3153838.help.text There are a LOT of them, and each time, the only translatable text is icon. What utility do these strings have? Is it worth our time to translate this same text, over and over? Timar wrote: clytie, This is not a problem of the format but the problem of the tool you use. There are tools which can be programmed to parse this format and handle tags correctly (as non-translatable placeables). These tools can also ignore the changes in markup, therefore you will have much less work during updates. Sometimes only the name of icon changes, sometimes inch is converted to cm in dimensions or vice versa. You are not obliged to use free po editors. I think there are better solutions which are not free but I value my time more than a few hundred Euros. Clytie wrote: timar: I work in a lot of other free-software projects, and haven't encountered this problem before. For one thing, they all work on the unique-string principle, so you don't have to translate the same text over and over, and secondly, my PO editors handle all those projects' files effectively. So I am inclined to see this as an OpenOffice.org issue. 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. 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. Ain Vagula - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
