Re: [l10n-dev] Re: problem strings in OmegaT
Aijin, Ok, very good. It would have been a very good surprise to see msgctxt appear somewhere though ;) Also, OmegaT 1.8 with a spellchecker (hunspell, works with OOo dictionaries) has been released in test version yesterday: http://mac4translators.blogspot.com/2008/03/omegat-173-18-19.html JC On 3 mars 08, at 17:56, Aijin Kim wrote: Hi JC, In OmegeT 1.7.3, msgctxt seems to be simply ignored. There is no display for msgctxt. What I meant was that OmegaT works ok with 'msgid' and 'msgstr' fields regardless of msgctxt field. Regards, Aijin Jean-Christophe Helary 쓴 글: Aijin, Thanks for your comments. Yes, I agree that it'd be the best way to switch the style from msgid_comment to msgctxt. I also confirmed that msgctxt works ok in OmegaT. I did not have the time to check. What do you mean by "msgctxt works ok in OmegaT" ? Is it displayed separately as a comment or is it simply ignored ? Jean-Christophe Helary K.K. DOUBLET - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Re: problem strings in OmegaT
Hi JC, In OmegeT 1.7.3, msgctxt seems to be simply ignored. There is no display for msgctxt. What I meant was that OmegaT works ok with 'msgid' and 'msgstr' fields regardless of msgctxt field. Regards, Aijin Jean-Christophe Helary 쓴 글: Aijin, Thanks for your comments. Yes, I agree that it'd be the best way to switch the style from msgid_comment to msgctxt. I also confirmed that msgctxt works ok in OmegaT. I did not have the time to check. What do you mean by "msgctxt works ok in OmegaT" ? Is it displayed separately as a comment or is it simply ignored ? Jean-Christophe Helary http://mac4translators.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Re: problem strings in OmegaT
Aijin, Thanks for your comments. Yes, I agree that it'd be the best way to switch the style from msgid_comment to msgctxt. I also confirmed that msgctxt works ok in OmegaT. I did not have the time to check. What do you mean by "msgctxt works ok in OmegaT" ? Is it displayed separately as a comment or is it simply ignored ? Jean-Christophe Helary http://mac4translators.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Re: problem strings in OmegaT
On Monday 03 March 2008 05:03:58 Aijin Kim wrote:
> So now, I'd like to suggest to switch OO.o po files in sunvirtuallab to
> msgctxt.
+1
--
Best regards,
Rail Aliev
http://{ru,tr}.openoffice.org
The human race has one really effective weapon, and that is laughter.
-- Mark Twain
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Re: problem strings in OmegaT
Oops, below message should be "If there is no objection, I'm going to apply the new style from the next Pootle update." Thanks, Aijin Aijin Kim 쓴 글: > Hi Friedel, > > Thanks for your comments. Yes, I agree that it'd be the best way to > switch the style from msgid_comment to msgctxt. I also confirmed that > msgctxt works ok in OmegaT. > > So now, I'd like to suggest to switch OO.o po files in sunvirtuallab to > msgctxt. > If there is any objection, I'm going to apply the new style from the > next Pootle update. If you have any concern or comment, please let me know. > > Thanks for all your help, > Aijin > > > F Wolff 쓴 글: > >> I think msgctxt might be the best way to go, except if some team really >> wants to support some tool that doesn't yet support it well. From my >> understanding, the current versions of OmegaT will already work better >> with the msgctxt-type files, simply because the msgid will now always >> just contain the text for translation. This should enable the normal >> translation workflow of PO files in OmegaT, and should mean that the TM, >> etc. should work properly. (Of course, there might still be issues more >> generally about PO support, but at least it should be better than with >> the msgid comments). Unless anybody objects, I think going with msgctxt >> should be a good goal for just about everybody. I understand that Ain >> (not Aijin:-) has also already migrated that way. >> >> I think it is also worthwhile noting that the msgid comment was >> introduced by KDE before msgctxt existed, and now even the KDE project >> does not use it anymore. Although the Translate Toolkit and Pootle >> support it quite well, I think, most other tools that don't support it >> yet, probably never will, as these type of files will probably gradually >> disappear :-) >> >> Friedel >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Re: problem strings in OmegaT
Hi Friedel, Thanks for your comments. Yes, I agree that it'd be the best way to switch the style from msgid_comment to msgctxt. I also confirmed that msgctxt works ok in OmegaT. So now, I'd like to suggest to switch OO.o po files in sunvirtuallab to msgctxt. If there is any objection, I'm going to apply the new style from the next Pootle update. If you have any concern or comment, please let me know. Thanks for all your help, Aijin F Wolff 쓴 글: > > I think msgctxt might be the best way to go, except if some team really > wants to support some tool that doesn't yet support it well. From my > understanding, the current versions of OmegaT will already work better > with the msgctxt-type files, simply because the msgid will now always > just contain the text for translation. This should enable the normal > translation workflow of PO files in OmegaT, and should mean that the TM, > etc. should work properly. (Of course, there might still be issues more > generally about PO support, but at least it should be better than with > the msgid comments). Unless anybody objects, I think going with msgctxt > should be a good goal for just about everybody. I understand that Ain > (not Aijin:-) has also already migrated that way. > > I think it is also worthwhile noting that the msgid comment was > introduced by KDE before msgctxt existed, and now even the KDE project > does not use it anymore. Although the Translate Toolkit and Pootle > support it quite well, I think, most other tools that don't support it > yet, probably never will, as these type of files will probably gradually > disappear :-) > > Friedel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Re: problem strings in OmegaT
Op Vrydag 2008-02-29 skryf Aijin Kim: > Hi JC, > > Thanks a lot for your kind explanation. > So you mean that you manually delete the msgid_comment part from each > target string? > If so, it should be better that source string doesn't include the > msgid_comment line in source string to avoid additional work, right? > > Now, I'm thinking if we need to use msgctxt style. Ain has confirmed > that poedit supports it. I'm not sure about OmegaT. > If OmegaT also supports msgctxt, it'd be good to change the format of po > files from next update. > > What do you think? > > Aijin > I think msgctxt might be the best way to go, except if some team really wants to support some tool that doesn't yet support it well. From my understanding, the current versions of OmegaT will already work better with the msgctxt-type files, simply because the msgid will now always just contain the text for translation. This should enable the normal translation workflow of PO files in OmegaT, and should mean that the TM, etc. should work properly. (Of course, there might still be issues more generally about PO support, but at least it should be better than with the msgid comments). Unless anybody objects, I think going with msgctxt should be a good goal for just about everybody. I understand that Ain (not Aijin:-) has also already migrated that way. I think it is also worthwhile noting that the msgid comment was introduced by KDE before msgctxt existed, and now even the KDE project does not use it anymore. Although the Translate Toolkit and Pootle support it quite well, I think, most other tools that don't support it yet, probably never will, as these type of files will probably gradually disappear :-) Friedel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Re: problem strings in OmegaT
On 29 févr. 08, at 17:20, Jean-Christophe Helary wrote: On 29 févr. 08, at 17:02, Aijin Kim wrote: Now, I'm thinking if we need to use msgctxt style. Ain has confirmed that poedit supports it. I'm not sure about OmegaT. If OmegaT also supports msgctxt, it'd be good to change the format of po files from next update. OmegaT will ignore its contents. It only sees msgid. I will put that as a RFE on OmegaT's site but it is unlikely to be implemented before a while. Jean-Christophe Helary http://mac4translators.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Re: problem strings in OmegaT
On 29 févr. 08, at 17:02, Aijin Kim wrote: Hi JC, Thanks a lot for your kind explanation. So you mean that you manually delete the msgid_comment part from each target string? If so, it should be better that source string doesn't include the msgid_comment line in source string to avoid additional work, right? That is correct. Now, I'm thinking if we need to use msgctxt style. Ain has confirmed that poedit supports it. I'm not sure about OmegaT. If OmegaT also supports msgctxt, it'd be good to change the format of po files from next update. OmegaT will ignore its contents. It only sees msgid. JC Jean-Christophe Helary 쓴 글: On 29 févr. 08, at 15:20, Aijin Kim wrote: Hi JC, I guess what Ain mentioned was that 'msgctxt' option during oo2po saves the comment line in another field rather that adding to msgid fileld. Then there won't be no change with msgid string. So for current po files, do you simply ignore the comment line in your translation? As far as OmegaT is concerned, yes. But OmegaT is even weirder than that :) Basically, OmegaT has been conceived for translating documents, monolingual documents. Not for working with intermediate localization formats. Basically it works that way: • It first parses the file, keeps the structure (skeleton) part in memory and puts all the translatable strings to the display. • The translator goes through segments one by one and types the translation by also referring to the available translation memories and glossaries. • When the translator wants to see the result, the translated files are build by using the skeleton in memory and by filling in with the translated strings. Anything that has not been translated is left with the source values. The problem with PO or XLIFF etc, it is that the "skeleton" of the file has placeholders already for source and target. Which means that OmegaT should read what it sees in source, consider what is already in target and put the translation in target if necessary. PO includes in itself sort of a "TM" function by adding "fuzzy" strings and by keeping the whole legacy translation in itself. In OmegaT this TM part is handled totally separately because monolingual documents are not supposed to come with such embedded data, at least not in the current CAT world. In the case of PO files, it needs to have empty msgstr so that it can pretend to work as for a "normal" monolingual document by considering exclusively the contents of msgid, and even if the msgstr is not empty it just ignores its contents (future developments are aiming at putting that contents automatically in TM): The process is then: parse what is in msgid, display for translation, and _rewrite_ the whole file with msgid=msgstr for places that have not been translated yet... Which is the reason why OmegaT is perfect for HTML, ODF and whatever is monolingual and works on a _document_ basis (cf the NetBeans l10n process), but not so good for intermediate or pre- processed formats (like the OOo and other PO based l10n processes). Eventually, the dev team will work on the issue of intermediate formats. But right now OmegaT will work best with "proper" msgid and empty msgstr, with all the legacy contents put in TMX or glossaries. That is what OmegaT is good at handling :) JC Thanks, Aijin Jean-Christophe Helary wrote: Hi all, Some strings of po files have a line which was added to make each msgid string be unique using --duplicates=msgid_comment option during executing oo2po. http://translate.sourceforge.net/wiki/toolkit/ duplicates_duplicatestyle How can OmegaT or poedit handle the added line? Since the string is a msgid it is handled as a source string and is displayed as translatable. ... thats one reason we switched to msgctxt comment style, where identifier is stored in separate field. See also http://vagula.blogspot.com/2008/02/attention-to-community-translators.html Ain, Sorry I don't understand your comment. What Aijin asked is how does OmegaT (and POedit, which I don't use) handle tweaked msgid. My reply was that it handles them as "normal" msgid. I did not see a reference to msgctxt. Jean-Christophe Helary http://mac4translators.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jean-Christophe Helary K.K. DOUBLET - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: [l10n-dev] Re: problem strings in OmegaT
Hi JC, Thanks a lot for your kind explanation. So you mean that you manually delete the msgid_comment part from each target string? If so, it should be better that source string doesn't include the msgid_comment line in source string to avoid additional work, right? Now, I'm thinking if we need to use msgctxt style. Ain has confirmed that poedit supports it. I'm not sure about OmegaT. If OmegaT also supports msgctxt, it'd be good to change the format of po files from next update. What do you think? Aijin Jean-Christophe Helary 쓴 글: On 29 févr. 08, at 15:20, Aijin Kim wrote: Hi JC, I guess what Ain mentioned was that 'msgctxt' option during oo2po saves the comment line in another field rather that adding to msgid fileld. Then there won't be no change with msgid string. So for current po files, do you simply ignore the comment line in your translation? As far as OmegaT is concerned, yes. But OmegaT is even weirder than that :) Basically, OmegaT has been conceived for translating documents, monolingual documents. Not for working with intermediate localization formats. Basically it works that way: • It first parses the file, keeps the structure (skeleton) part in memory and puts all the translatable strings to the display. • The translator goes through segments one by one and types the translation by also referring to the available translation memories and glossaries. • When the translator wants to see the result, the translated files are build by using the skeleton in memory and by filling in with the translated strings. Anything that has not been translated is left with the source values. The problem with PO or XLIFF etc, it is that the "skeleton" of the file has placeholders already for source and target. Which means that OmegaT should read what it sees in source, consider what is already in target and put the translation in target if necessary. PO includes in itself sort of a "TM" function by adding "fuzzy" strings and by keeping the whole legacy translation in itself. In OmegaT this TM part is handled totally separately because monolingual documents are not supposed to come with such embedded data, at least not in the current CAT world. In the case of PO files, it needs to have empty msgstr so that it can pretend to work as for a "normal" monolingual document by considering exclusively the contents of msgid, and even if the msgstr is not empty it just ignores its contents (future developments are aiming at putting that contents automatically in TM): The process is then: parse what is in msgid, display for translation, and _rewrite_ the whole file with msgid=msgstr for places that have not been translated yet... Which is the reason why OmegaT is perfect for HTML, ODF and whatever is monolingual and works on a _document_ basis (cf the NetBeans l10n process), but not so good for intermediate or pre-processed formats (like the OOo and other PO based l10n processes). Eventually, the dev team will work on the issue of intermediate formats. But right now OmegaT will work best with "proper" msgid and empty msgstr, with all the legacy contents put in TMX or glossaries. That is what OmegaT is good at handling :) JC Thanks, Aijin Jean-Christophe Helary wrote: Hi all, Some strings of po files have a line which was added to make each msgid string be unique using --duplicates=msgid_comment option during executing oo2po. http://translate.sourceforge.net/wiki/toolkit/ duplicates_duplicatestyle How can OmegaT or poedit handle the added line? Since the string is a msgid it is handled as a source string and is displayed as translatable. ... thats one reason we switched to msgctxt comment style, where identifier is stored in separate field. See also http://vagula.blogspot.com/2008/02/attention-to-community-translators.html Ain, Sorry I don't understand your comment. What Aijin asked is how does OmegaT (and POedit, which I don't use) handle tweaked msgid. My reply was that it handles them as "normal" msgid. I did not see a reference to msgctxt. Jean-Christophe Helary http://mac4translators.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jean-Christophe Helary K.K. DOUBLET - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Re: problem strings in OmegaT
On 29 févr. 08, at 15:56, Jean-Christophe Helary wrote: In OmegaT this TM part is handled totally separately because monolingual documents are not supposed to come with such embedded data, at least not in the current CAT world. Addendum: localization comments are not supposed to be embedded in monolingual documents, which is the reason OmegaT does not support them at all. It would eventually because there are comment/note placeholders in TMX files. But it is not for the current implementation of the code. And as far as I know, not planned in the next stable version (1.8) that will replace the current one (1.7.3, released a few days ago). Such profound modifications are likely to take place in the 1.9 code base, but this is a wholly different story. Jean-Christophe Helary http://mac4translators.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Re: problem strings in OmegaT
On 29 févr. 08, at 15:20, Aijin Kim wrote: Hi JC, I guess what Ain mentioned was that 'msgctxt' option during oo2po saves the comment line in another field rather that adding to msgid fileld. Then there won't be no change with msgid string. So for current po files, do you simply ignore the comment line in your translation? As far as OmegaT is concerned, yes. But OmegaT is even weirder than that :) Basically, OmegaT has been conceived for translating documents, monolingual documents. Not for working with intermediate localization formats. Basically it works that way: • It first parses the file, keeps the structure (skeleton) part in memory and puts all the translatable strings to the display. • The translator goes through segments one by one and types the translation by also referring to the available translation memories and glossaries. • When the translator wants to see the result, the translated files are build by using the skeleton in memory and by filling in with the translated strings. Anything that has not been translated is left with the source values. The problem with PO or XLIFF etc, it is that the "skeleton" of the file has placeholders already for source and target. Which means that OmegaT should read what it sees in source, consider what is already in target and put the translation in target if necessary. PO includes in itself sort of a "TM" function by adding "fuzzy" strings and by keeping the whole legacy translation in itself. In OmegaT this TM part is handled totally separately because monolingual documents are not supposed to come with such embedded data, at least not in the current CAT world. In the case of PO files, it needs to have empty msgstr so that it can pretend to work as for a "normal" monolingual document by considering exclusively the contents of msgid, and even if the msgstr is not empty it just ignores its contents (future developments are aiming at putting that contents automatically in TM): The process is then: parse what is in msgid, display for translation, and _rewrite_ the whole file with msgid=msgstr for places that have not been translated yet... Which is the reason why OmegaT is perfect for HTML, ODF and whatever is monolingual and works on a _document_ basis (cf the NetBeans l10n process), but not so good for intermediate or pre-processed formats (like the OOo and other PO based l10n processes). Eventually, the dev team will work on the issue of intermediate formats. But right now OmegaT will work best with "proper" msgid and empty msgstr, with all the legacy contents put in TMX or glossaries. That is what OmegaT is good at handling :) JC Thanks, Aijin Jean-Christophe Helary wrote: Hi all, Some strings of po files have a line which was added to make each msgid string be unique using --duplicates=msgid_comment option during executing oo2po. http://translate.sourceforge.net/wiki/toolkit/ duplicates_duplicatestyle How can OmegaT or poedit handle the added line? Since the string is a msgid it is handled as a source string and is displayed as translatable. ... thats one reason we switched to msgctxt comment style, where identifier is stored in separate field. See also http://vagula.blogspot.com/2008/02/attention-to-community-translators.html Ain, Sorry I don't understand your comment. What Aijin asked is how does OmegaT (and POedit, which I don't use) handle tweaked msgid. My reply was that it handles them as "normal" msgid. I did not see a reference to msgctxt. Jean-Christophe Helary http://mac4translators.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jean-Christophe Helary K.K. DOUBLET - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Re: problem strings in OmegaT
Poedit supports from 1.3.8, dont know about OmegaT. ain On Fri, Feb 29, 2008 at 8:44 AM, Aijin Kim <[EMAIL PROTECTED]> wrote: > Hi Ain, > > Thanks for you comment. > Do you know if Poedit or OmegaT support msgctxt? > > Aijin > > > > Ain Vagula wrote: > >> Since the string is a msgid it is handled as a source string and is > >> displayed as translatable. > >> > >> > >> > > > > ... thats one reason we switched to msgctxt comment style, where > > identifier is stored in separate field. See also > > http://vagula.blogspot.com/2008/02/attention-to-community-translators.html > > > > ain > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Re: problem strings in OmegaT
Dick Groskamp wrote: [...] AFAIK most Dutch translators use OmegaT but otherwise we have to make some kind of switch It's far from something I'm specialized in, but the last time I made a contribution, I used Pootling (0.2.0). Maybe that dóes make a difference? Pls. send me something to try. regards, Cor -- "The Year of 3" -2008- "Het jaar van 3" Cor Nouws Arnhem - Netherlands - nl.OpenOffice.org - marketing contact - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Re: problem strings in OmegaT
Hi Ain, Thanks for you comment. Do you know if Poedit or OmegaT support msgctxt? Aijin Ain Vagula wrote: Since the string is a msgid it is handled as a source string and is displayed as translatable. ... thats one reason we switched to msgctxt comment style, where identifier is stored in separate field. See also http://vagula.blogspot.com/2008/02/attention-to-community-translators.html ain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Re: problem strings in OmegaT
Hi JC, I guess what Ain mentioned was that 'msgctxt' option during oo2po saves the comment line in another field rather that adding to msgid fileld. Then there won't be no change with msgid string. So for current po files, do you simply ignore the comment line in your translation? Thanks, Aijin Jean-Christophe Helary wrote: Hi all, Some strings of po files have a line which was added to make each msgid string be unique using --duplicates=msgid_comment option during executing oo2po. http://translate.sourceforge.net/wiki/toolkit/ duplicates_duplicatestyle How can OmegaT or poedit handle the added line? Since the string is a msgid it is handled as a source string and is displayed as translatable. ... thats one reason we switched to msgctxt comment style, where identifier is stored in separate field. See also http://vagula.blogspot.com/2008/02/attention-to-community-translators.html Ain, Sorry I don't understand your comment. What Aijin asked is how does OmegaT (and POedit, which I don't use) handle tweaked msgid. My reply was that it handles them as "normal" msgid. I did not see a reference to msgctxt. Jean-Christophe Helary http://mac4translators.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Re: problem strings in OmegaT
Hi all, Some strings of po files have a line which was added to make each msgid string be unique using --duplicates=msgid_comment option during executing oo2po. http://translate.sourceforge.net/wiki/toolkit/ duplicates_duplicatestyle How can OmegaT or poedit handle the added line? Since the string is a msgid it is handled as a source string and is displayed as translatable. ... thats one reason we switched to msgctxt comment style, where identifier is stored in separate field. See also http://vagula.blogspot.com/2008/02/attention-to-community-translators.html Ain, Sorry I don't understand your comment. What Aijin asked is how does OmegaT (and POedit, which I don't use) handle tweaked msgid. My reply was that it handles them as "normal" msgid. I did not see a reference to msgctxt. Jean-Christophe Helary http://mac4translators.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Re: problem strings in OmegaT
On Fri, Feb 29, 2008 at 7:04 AM, Jean-Christophe Helary <[EMAIL PROTECTED]> wrote: > > On 29 févr. 08, at 12:50, Aijin Kim wrote: > > > Hi Dick, > > I don't have much experience with OmegaT. I think it's the best way > > to ask community's help on this. :) > > > > Hi all, > > Some strings of po files have a line which was added to make each > > msgid string be unique using --duplicates=msgid_comment option > > during executing oo2po. > > http://translate.sourceforge.net/wiki/toolkit/ > > duplicates_duplicatestyle > > > > How can OmegaT or poedit handle the added line? Is there any way to > > hide the line from source string or can we simply ignore the line > > when translating? > > I can see Pootle handles the line and hide it from source string for > > online translation. But not sure in terms of offline editors. > > Since the string is a msgid it is handled as a source string and is > displayed as translatable. > > ... thats one reason we switched to msgctxt comment style, where identifier is stored in separate field. See also http://vagula.blogspot.com/2008/02/attention-to-community-translators.html ain
Re: [l10n-dev] Re: problem strings in OmegaT
On 29 févr. 08, at 12:50, Aijin Kim wrote: Hi Dick, I don't have much experience with OmegaT. I think it's the best way to ask community's help on this. :) Hi all, Some strings of po files have a line which was added to make each msgid string be unique using --duplicates=msgid_comment option during executing oo2po. http://translate.sourceforge.net/wiki/toolkit/ duplicates_duplicatestyle How can OmegaT or poedit handle the added line? Is there any way to hide the line from source string or can we simply ignore the line when translating? I can see Pootle handles the line and hide it from source string for online translation. But not sure in terms of offline editors. Since the string is a msgid it is handled as a source string and is displayed as translatable. Jean-Christophe Helary http://mac4translators.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
