Menu ▾ ▴

#960 PO filter: allow translating blank source segments

3.1
closed-fixed
Enrique Estévez
None
5
2014-05-19
2014-02-25
jordis
No

This feature request derives from this thread:
http://sourceforge.net/mailarchive/message.php?msg_id=31442669
Excerpt:
I'm translating a .po file witch has this segment:
For reference, file is here:
http://pootle.softcatala.org/ca/mozilla/calendar/chrome/calendar/calendar-event-dialog.dtd.po/translate/?unit=301409
#. LOCALIZATON NOTE
#. Some languages use a preposition when describing dates:
#. Portuguese: 6 de Setembro
#. English: 6 [of] September
#. event.recurrence.pattern.yearly.of.label is "of" in
#. Edit recurrence window -> Recurrence pattern -> Repeat yearly
#: event.recurrence.pattern.yearly.of.label
msgctxt "event.recurrence.pattern.yearly.of.label"
msgid ""
msgstr ""

Given the localization note, I should translate it as "de":
#. LOCALIZATON NOTE
#. Some languages use a preposition when describing dates:
#. Portuguese: 6 de Setembro
#. English: 6 [of] September
#. event.recurrence.pattern.yearly.of.label is "of" in
#. Edit recurrence window -> Recurrence pattern -> Repeat yearly
#: event.recurrence.pattern.yearly.of.label
msgctxt "event.recurrence.pattern.yearly.of.label"
msgid ""
msgstr "de"

But OmegaT completely ignores such blank segments. I do not see it in
the Editor.

Discussion

  • Enrique Estévez

    Enrique Estévez - 2014-02-27

    I am not good developer, but I want to try to help.

    In my opinion, OmegaT seems to be developed to ignore this type of segments. In several files, I found messages of the type:
    - if the source string is empty, don't add it to TM
    - empty segment
    - empty string - not need to save
    - skip empty segments
    I have added a bit of code in the PoFilterjava file and have commented several pieces of code in another files and it seems to work.

    This would be the 1 option. But I think that it is not good. This option can have collateral effects in the another filters. I attached the patch and I go to work in a second option.

    In the 2 option, I will create methods or functions instead to modify the generics that use the another filters. I think that it is not the best option, but it can be good, already that this option must not have collateral effects in the another filters.

     
    pofilter_allow_editing_of_blank_source_segments.diff

  • Didier Briel

    Didier Briel - 2014-02-27

    You are right, touching ParseEntry cannot be done, as it's much too sensitive.

    In addition, even if touching only the PO filter, the point is not to allow to translate blank segments (how OmegaT could tell one blank segment from another?), but to somehow use msgctxt to create a meaningful source segment. For instance (this is just an example), the source segment could contain "event.recurrence.pattern.yearly.of.label"

    Didier

     

  • Enrique Estévez

    Enrique Estévez - 2014-02-27

    You are right, touching ParseEntry cannot be done, as it's much too sensitive.

    I have tryed to duplicate the methods/functions, but I have not got of the all. In the ParseEntry.java file, into the fileFinished method/function I am not able to do the follow:

    • // Here there is that to check that the segment belongs to a .po file
    • // I do not know how do this
    • if(item.segmentSource.length()> 0 && )

    If this could do, maybe it would be a good option (development). I attached the development.

    Even so, once done the work, the proposition does not convince me. But could be a temporal solution that it can use as a option in the filter (There still would be to develop it).

    In addition, even if touching only the PO filter, the point is not to allow to translate blank segments (how OmegaT could tell one blank segment from another?), but to somehow use msgctxt to create a meaningful source segment.

    I understand the problem that you comment me. And there are two ways to solve it.
    Manually: If the translator creates alternative translations for each empty segment, OmegaT will use the msgctxt and the filename to differentiate them.

    Automatically: I have been not able to do it. The idea is: When OmegaT detects a empty segment with translation, instead to create a default translation into the translation memory, should create a alternative translation.

    <tu>
  <prop type="file">proba.po</prop>
  <prop type="path">event.recurrence.pattern.yearly.of.label</prop>
  <tuv lang="EN-US">
    <seg></seg>
  </tuv>
  <tuv lang="PL" changeid="kike" changedate="20140226T235217Z" creationid="kike" creationdate="20140226T235217Z">
    <seg>de</seg>
  </tuv>
</tu>

    For instance (this is just an example), the source segment could contain "event.recurrence.pattern.yearly.of.label"

    I will also try with this.

     
    pofilter_allow_editing_of_blank_source_segments_option2.diff

  • Didier Briel

    Didier Briel - 2014-02-28

    In my humble opinion, I still think you are on the wrong track, and I will not integrate such developments.

    If the file contains hundreds of segments, it is not realistic to present a blank screen Editor to the translator and to ask them to create alternative translations for each of them.

    I have the impression that when msgctxt contains something (e.g., "event.recurrence.pattern.yearly.of.label") and msgid is empty, the real source segment is msgctxt, even if is not to be translated literally.
    I.e., the translation of "event.recurrence.pattern.yearly.of.label" is "de".

    That way, you don't have to do convoluted things or re-invent the wheel.

    Didier

     

  • Enrique Estévez

    Enrique Estévez - 2014-02-28

    You are right.

    I attach a new patch.

    If the source segment is empty and there is a reference, then it copy the reference of the segment and the localization note into the source segment.
    It does not copy the context because sometimes there is not.

    It seems that works.

    I am doing this via a option in the filter. I think that it must be an option that come disabled default.

     
    pofilter_allow_editing_of_blank_source_segments_vf.diff

  • Enrique Estévez

    Enrique Estévez - 2014-03-01

    Possible bug in the po filter, in one of its options.

    Testing the development I think have found a bug in the po filter. I know that the filter fails, but I don't know where is the problem. The problem already exists in the filter before of the patch.

    When you active or desactive the option:
    - Allow blank translations in the target files
    After of reload the project, in the console I see a java.lang.NullPointerException.

    A piece of output by screen:

    15242: Info: Project loading start (LOG_DATAENGINE_LOAD_START)
    15242: Error: java.lang.NullPointerException
    15242: Error: at org.omegat.core.data.RealProject.iterateByDefaultTranslations(RealProject.java:1367)
    15242: Error: at org.omegat.gui.multtrans.MultipleTransFindThread.search(MultipleTransFindThread.java:59)
    15242: Error: at org.omegat.gui.multtrans.MultipleTransFindThread.search(MultipleTransFindThread.java:45)
    15242: Error: at org.omegat.gui.common.EntryInfoSearchThread.run(EntryInfoSearchThread.java:96)
    15242: Info: Event: project change - "SAVE" (LOG_INFO_EVENT_PROJECT_CHANGE)

    or this another:

    15242: Info: Project loading start (LOG_DATAENGINE_LOAD_START)
    15242: Info: Event: project change - "SAVE" (LOG_INFO_EVENT_PROJECT_CHANGE)
    15242: Info: Event: project change - "CLOSE" (LOG_INFO_EVENT_PROJECT_CHANGE)
    15242: Error: Uncatched exception in thread [AWT-EventQueue-0]
    15242: Error: java.lang.NullPointerException
    15242: Error: at org.omegat.core.data.RealProject.getTranslationInfo(RealProject.java:1270)
    15242: Error: at org.omegat.gui.editor.SegmentBuilder.createSegmentElement(SegmentBuilder.java:178)
    15242: Error: at org.omegat.gui.editor.EditorController.loadDocument(EditorController.java:500)
    15242: Error: at org.omegat.gui.editor.EditorController.removeFilter(EditorController.java:1816)
    15242: Error: at org.omegat.gui.editor.EditorController$1.onProjectChanged(EditorController.java:202)
    15242: Error: at org.omegat.core.CoreEvents$1.run(CoreEvents.java:134)
    15242: Error: at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
    15242: Error: at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
    15242: Error: at java.awt.EventQueue.access$200(EventQueue.java:103)
    15242: Error: at java.awt.EventQueue$3.run(EventQueue.java:694)
    15242: Error: at java.awt.EventQueue$3.run(EventQueue.java:692)
    15242: Error: at java.security.AccessController.doPrivileged(Native Method)
    15242: Error: at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
    15242: Error: at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
    15242: Error: at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
    15242: Error: at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
    15242: Error: at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
    15242: Error: at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
    15242: Error: at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
    15242: Error: at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
    15242: Info: Load project source files: 88ms

     

  • Didier Briel

    Didier Briel - 2014-03-01

    If possible, please open a new bug report, with a file allowing to reproduce the issue. (Generally speaking, it is not good practise to mix issues inside the same report.)

    Didier

     

  • Didier Briel

    Didier Briel - 2014-04-30
    • summary: PO filter: allow editing of blank source segments (OmT ignores them completely) --> PO filter: allow translating blank source segments
    • assigned_to: Enrique Estévez
    • Group: 2.6 --> 3.1
     

  • Didier Briel

    Didier Briel - 2014-04-30

    Implemented in SVN (/trunk).

    Didier

     

  • Didier Briel

    Didier Briel - 2014-04-30
    • status: open --> open-fixed
     

  • Didier Briel

    Didier Briel - 2014-05-19
    • status: open-fixed --> closed-fixed
     

  • Didier Briel

    Didier Briel - 2014-05-19

    Closing.

    Implemented in the released version 3.1.1 of OmegaT.

    Didier

     

Log in to post a comment.