#368 PO: bad handling of already translated strings


When a PO file with translated msgstr is loaded, even if nothing has been input, the target PO is transformed into a monolingual PO file with msgid=msgstr.

The expected behavior is that nothing is changed at all.

Even in the case where some segments have been changed, only those should show modifications in the target file.

If _that_ could be implemented it would be a huge step forward PO proper support of OmegaT.



  • Wes Freeman

    Wes Freeman - 2009-01-15

    I think I will look into this, JC, as I am doing a bunch of PO translations for fedora, and it would be a big help to me. A lot of the files I'm working with are 50% translated, and I would like to use OmegaT for them, but without being able to see the previous translations, it's kind of silly.


  • Jean-Christophe Helary

    I'm just thinking that instead of the hack we have now, what about using the whole msgid/msgstr block in source ?

    PO translators would then have the totality of the information (including meta stuff, fuzzy etc) and would be able to just type into the msgstr part, which would be a _huge_ improvement over what we have now, including the fact that since everything is in source, untranslated target segments would remain exactly as the source is, unlike what happens now...

    For ex:

    <segment nnn> ....

    #: draw_sector.xhp#par_id3148868.35.help.text
    #, fuzzy
    msgid ""
    "To create a circle by dragging from the center, press <switchinline "
    "select=\"sys\"><caseinline select=\"MAC\">Option</caseinline><defaultinline>Alt<"
    "/defaultinline></switchinline> while dragging."
    msgstr ""
    "円を作成するには、中心からドラッグして、ドラッグしながら、<switchinline select=\"sys\"><caseinline "
    "select=\"MAC\">Option "
    "</caseinline><defaultinline>Alt</defaultinline></switchinline> キーを押します。"

    ....</end segment>

    Reference TMX would not be less useful since untranslated segments would not have a msgstr part and thus the match would be computed based on the msgid contents mostly.

  • Jean-Christophe Helary

    • milestone: 662058 --> 2.0
  • Wes Freeman

    Wes Freeman - 2009-01-15

    What you describe sounds like a pretty big improvement.

    I'm envisioning something like what I've edited below, although ideally the comment part of the text wouldn't be in the segment (and thus would be ignored by the translation memory). I'll start with what you mentioned, as an exploratory type exercise, although I think the automatic translation and memory will be a bit corrupted by the extra stuff of PO files (having both msgid and msgstr, and the comments, etc.). Ideally it would automatically update the fuzzy flag after being translated, as well (instead of having to manually remove it).

    #: draw_sector.xhp#par_id3148868.35.help.text
    #, fuzzy
    # etc. etc.
    To create a circle by dragging from the center, press <switchinline
    "/defaultinline></switchinline> while dragging."
    <segment nnn>
    select=\"sys\"><caseinline "
    "select=\"MAC\">Option "
    キーを押します。"</end segment>

    ...where the comments are listed above the msgid, and the segment contains the original translation. Maybe it could be highlighted a certain color, if it is an existing translation, and not one you did, or something...

  • Wes Freeman

    Wes Freeman - 2009-01-15

    Your change was fairly simple. I still have a few glitches with the header, but tomorrow I can probably finish it. I'm not sure it should go into production like this, but it is a lot more usable for my purposes! I'll attach a screenshot.

  • Jean-Christophe Helary

    Yes, and my idea is certain to be refused by Didier ;)

    There were discussions about putting existing msgstr automatically in TMX at load.

    Also, check this:

    So, maybe the solution is to have the source part display the whole thing but use the input only for msgstr. Anyway, if you find a solution to PO handling that will be a major improvement.

  • Jean-Christophe Helary

    Now, I am thinking, what about making that an option in the PO file filter dialog ?

    Either translators work with "simple" POs in which case the default behavior is way enough, or they work with complex ones, in which case OmegaT can be told to choose the "new" behavior by default...

  • Wes Freeman

    Wes Freeman - 2009-01-15

    That's true, it could be optional. I still dislike treating the whole thing together as a string... it seems like it would clog up the memory. It would be nice if the memory from these PO files could be reused in other software localization projects. There should be a better way to handle it. I'm not familiar enough with the code to say off the top of my head whether it will be easy or hard...

  • Didier Briel

    Didier Briel - 2009-01-15

    [ 1651254 ] Read existing translations from source documents
    seems to me a more proper response to the problem

    And the discussion here (about reusing existing translation, and providing context), does not seem really inline with the original report:
    Don't change entry where no translation has been provided.


  • Jean-Christophe Helary

    Yes, but in the case of PO (and XLIFF) there are other fields besides for "source" and "target" and only reading target in memory for automatic propagation does not guaranty that the other fields are properly reproduced in target. So it seems to me the issue is slightly different.

  • Didier Briel

    Didier Briel - 2009-02-05
    • assigned_to: nobody --> wes_freeman
  • Didier Briel

    Didier Briel - 2009-09-22
    • assigned_to: wes_freeman --> alex73
    • status: open --> closed-fixed

Log in to post a comment.