Elvas Tower: Compilation of locale-DLLs fails due to new Feature in POedit / *.PO-Files - Elvas Tower

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Compilation of locale-DLLs fails due to new Feature in POedit / *.PO-Files Rate Topic: -----

#1 User is offline   markus_GE 

  • Executive Vice President
  • PipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 4,862
  • Joined: 07-February 13
  • Gender:Male
  • Location:Leoben, Styria, Austria, Europe
  • Simulator:ORTS / MSTS
  • Country:

Posted 10 June 2020 - 03:15 PM

<Admin comment 2020-06-08>
Thread moved here from the private ORTS development forum so it can benefit a wider range of translators who do not necessarily have access to the private forum.

Hi Guys,

I recently had the Appveyor CI build (as well as the manually initiated DLL-compilation via update-DLL.bat) fail on an update to the German translations. Carlo kindly helped me identify the culprit and the complete "discussion" (mostly my findings in chronological order) can be found in PR #211 @ GitHub.

In a nutshell, what happened is...
  • The German translations have not been extensively updated since 2016, which I have slowly been correcting since March.
  • Since then, a new Version of POedit has been released which includes a new feature that also displays the old version of a string or translation in case such str / trl is changed in the code (if more explanation is needed, pls just leave a note :) )
  • Said previous version of a string / translation is saved in the PO files with a "#|" prefix, like this:
    OLD VERSION
    msgid "Ejector"
    

    NEW VERSION:
    #| msgid "Ejector"
    msgid "LargeEjector"
  • Any attempt to compile locale DLL files from PO files containing such an entry fails (both th Appveyor CI build and the manually-initiated update-DLL.bat method fail or stall).
  • Manually removing all those entries cures the problem.
  • Those lines are a good help for translators, though, so keeping them would be cool. Also, manually removing them can be a real PITA.
  • Even when they have been removed, subsequent updated of the PO files are likely to re-introduce similar entries since I have not (yet) been able to stop POedit creating them.

What could there be done to work around this problem?

Cheers, Markus

PS: The Problem has only surfaced now since no strings seem to have changed in the modules whose translations I already updated so far - note, POedit has not been updated since I started these efforts.

#2 User is offline   perpetualKid 

  • Fireman
  • Group: Status: Active Member
  • Posts: 190
  • Joined: 10-June 18
  • Gender:Male
  • Simulator:OR
  • Country:

Posted 16 June 2020 - 11:25 AM

 markus_GE, on 10 June 2020 - 03:15 PM, said:

Hi Guys,

I recently had the Appveyor CI build (as well as the manually initiated DLL-compilation via update-DLL.bat) fail on an update to the German translations. Carlo kindly helped me identify the culprit and the complete "discussion" (mostly my findings in chronological order) can be found in PR #211 @ GitHub.

In a nutshell, what happened is...
  • The German translations have not been extensively updated since 2016, which I have slowly been correcting since March.
  • Since then, a new Version of POedit has been released which includes a new feature that also displays the old version of a string or translation in case such str / trl is changed in the code (if more explanation is needed, pls just leave a note :) )
  • Said previous version of a string / translation is saved in the PO files with a "#|" prefix, like this:
    OLD VERSION
    msgid "Ejector"
    

    NEW VERSION:
    #| msgid "Ejector"
    msgid "LargeEjector"
  • Any attempt to compile locale DLL files from PO files containing such an entry fails (both th Appveyor CI build and the manually-initiated update-DLL.bat method fail or stall).
  • Manually removing all those entries cures the problem.
  • Those lines are a good help for translators, though, so keeping them would be cool. Also, manually removing them can be a real PITA.
  • Even when they have been removed, subsequent updated of the PO files are likely to re-introduce similar entries since I have not (yet) been able to stop POedit creating them.

What could there be done to work around this problem?

Cheers, Markus

PS: The Problem has only surfaced now since no strings seem to have changed in the modules whose translations I already updated so far - note, POedit has not been updated since I started these efforts.


my preliminary research says that someone would have to touch the GNU.Gettext.Msgfmt which OR uses as part of the GNU.Gettext package for translation. The original C#/.NET version of GNU.Gettext seems no longer maintained so I doubt there would be updates coming from the official sources. The source is available as part of OR sources (Source\3rdPartyLibs\GNU.Gettext).

#3 User is offline   markus_GE 

  • Executive Vice President
  • PipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 4,862
  • Joined: 07-February 13
  • Gender:Male
  • Location:Leoben, Styria, Austria, Europe
  • Simulator:ORTS / MSTS
  • Country:

Posted 29 June 2020 - 12:41 PM

Hi perpetualKid,

thank you for your info. That's a point to start from, at least IF...

... one were brave enough to try and work this out (which I'm not sure I could do). Not promising anything here, but maybe I'll have the time to at least take look at it myself if I can find time while working a summer job and studying.

In the meantime, though, I'll resort to using an older version of POedit (should still have the installer from 2014 floating around somewhere) or maybe come up with a macro for Notepad++ to strip out all the lines causing havoc...

Cheers, Markus


PS: sorry for the late reply. I have been busy (and will continue to be) studying for my exam in electrical engineering this THU.

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users