ANN: Better Translation Manager released

[Anders Melander 1782]

25 minutes ago, DFenix said:

Is it not compatible to build in x64?

Yes - and it works for me.

Does it fail on every target project you run it against?

 

Why do you want it as a 64-bit executable? I don't think there should be any need for it as the memory usage is quite modest when building resource modules.

[DFenix 0]

6 hours ago, Anders Melander said:

Yes - and it works for me.

Does it fail on every target project you run it against?

 

Why do you want it as a 64-bit executable? I don't think there should be any need for it as the memory usage is quite modest when building resource modules.

Yes, it fails on each projects.

Just it is only a test to build my resources with this tool. My main project is built only on 64-bits and just avoid to build with 32-bits anymore.

Anyway, I think I found the issue. It is on the amLocalization.ResourceWriter.pas, here there is a pointer variable defined only 32-bits, I mean like so:

FResourceHandle: Cardinal;  //must be HWND or NativeUInt

Just changed it, and it starts to work fine built againt 64-bits 🙂

I think this is the reason why sometime it works because the allocated memory is not big.

Hope is can help and thanks.

[Anders Melander 1782]

6 minutes ago, DFenix said:

My main project is built only on 64-bits and just avoid to build with 32-bits anymore.

Even if your target project is 64-bit you don't need the resource builder to be 64-bit. The 32-bit build works with both 32- and 64-bit targets.

 

6 minutes ago, DFenix said:

Anyway, I think I found the issue. It is on the amLocalization.ResourceWriter.pas, here there is a pointer variable defined only 32-bits, I mean like so:

FResourceHandle: Cardinal;  //must be HWND or NativeUInt

Yes, you're right. It should be a THandle or a NativeUInt. I have pushed the fix. Thanks.

[DFenix 0]

13 hours ago, Anders Melander said:

Even if your target project is 64-bit you don't need the resource builder to be 64-bit. The 32-bit build works with both 32- and 64-bit targets.

 

Yes, you're right. It should be a THandle or a NativeUInt. I have pushed the fix. Thanks.

Thanks to you Anders,

 

Is there any result difference if I build the resources binaries in x64 against x86?

Sorry for persisting, but I have an automated machine that only build projects against 64-bits

 

My idea is only to use the  ResourceModuleBuilder console to create my binaries resources but with my own resource project format.

[Anders Melander 1782]

5 minutes ago, DFenix said:

Is there any result difference if I build the resources binaries in x64 against x86?

No.

A resource module is just a PE file (a DLL) with a resource section but without any code.

 

8 minutes ago, DFenix said:

I have an automated machine that only build projects against 64-bits

That's how I use it too.

I use Bamboo with the following config for the BTM task (XXX is the target project name). The target is a 64-bit exe.

• Executable: c:\Tools\Better Translation Manager\amResourceModuleBuilder.exe
• Argument: "${bamboo.build.working.directory}\translation\XXX.xlat" -v -b -n:0 "-s:${bamboo.build.working.directory}\bin\XXX.exe" "-y:${bamboo.build.working.directory}\bin\XXX.drc" "-o:${bamboo.build.working.directory}\bin"

 

7 minutes ago, DFenix said:

My idea is only to use the  ResourceModuleBuilder console to create my binaries resources but with my own resource project format.

What do you mean by "my own resource project format."?

[Anders Melander 1782]

2 minutes ago, Anders Melander said:

A resource module is just a PE file (a DLL) with a resource section but without any code.

The PE stub I use is defined in amLocalization.ResourceWriter.pas (see below).

If a file named EmptyResourceModule.dll exists in the same folder as BTM then that file will be used as the stub. Otherwise the stub is loaded from a resource (see Source\Resources folder) and finally if that resource doesn't exist the hardcoded stub below will be used.

 

const
  sResourceModuleStub = 'EmptyResourceModule.dll';
  sResourceModuleStubRes = 'EmptyResourceModule'; // Name of above file as an embedded resource

  // The following is the content of the file specified by the sResourceModuleStub constant.
  // It should be a minimal (i.e. no code) PE module containing nothing but a resource section without any resources.
  sResourceModuleData : AnsiString =
    #$4D#$5A#$90#$00#$03#$00#$00#$00#$04#$00#$00#$00#$FF#$FF#$00#$00#$B8#$00#$00#$00#$00#$00#$00#$00#$40#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$B0#$00#$00#$00+
    #$0E#$1F#$BA#$0E#$00#$B4#$09#$CD#$21#$B8#$01#$4C#$CD#$21#$54#$68#$69#$73#$20#$70#$72#$6F#$67#$72#$61#$6D#$20#$63#$61#$6E#$6E#$6F+
    #$74#$20#$62#$65#$20#$72#$75#$6E#$20#$69#$6E#$20#$44#$4F#$53#$20#$6D#$6F#$64#$65#$2E#$0D#$0D#$0A#$24#$00#$00#$00#$00#$00#$00#$00+
    #$37#$CF#$3C#$DF#$73#$AE#$52#$8C#$73#$AE#$52#$8C#$73#$AE#$52#$8C#$E1#$F0#$AD#$8C#$72#$AE#$52#$8C#$E4#$F0#$50#$8D#$72#$AE#$52#$8C+
    #$52#$69#$63#$68#$73#$AE#$52#$8C#$00#$00#$00#$00#$00#$00#$00#$00#$50#$45#$00#$00#$4C#$01#$02#$00#$B0#$66#$81#$5A#$00#$00#$00#$00+
    #$00#$00#$00#$00#$E0#$00#$02#$21#$0B#$01#$0E#$00#$00#$00#$00#$00#$00#$04#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$10#$00#$00+
    #$00#$10#$00#$00#$00#$00#$00#$10#$00#$10#$00#$00#$00#$02#$00#$00#$06#$00#$00#$00#$00#$00#$00#$00#$06#$00#$00#$00#$00#$00#$00#$00+
    #$00#$30#$00#$00#$00#$02#$00#$00#$00#$00#$00#$00#$02#$00#$40#$05#$00#$00#$10#$00#$00#$10#$00#$00#$00#$00#$10#$00#$00#$10#$00#$00+
    #$00#$00#$00#$00#$10#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$20#$00#$00#$10#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$10#$00#$00#$1C#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$2E#$72#$64#$61#$74#$61#$00#$00#$70#$00#$00#$00#$00#$10#$00#$00#$00#$02#$00#$00#$00#$02#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$40#$00#$00#$40#$2E#$72#$73#$72#$63#$00#$00#$00#$10#$00#$00#$00#$00#$20#$00#$00+
    #$00#$02#$00#$00#$00#$04#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$40#$00#$00#$40#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$B0#$66#$81#$5A#$00#$00#$00#$00#$0D#$00#$00#$00#$40#$00#$00#$00#$1C#$10#$00#$00#$1C#$02#$00#$00#$00#$00#$00#$00+
    #$00#$10#$00#$00#$1C#$00#$00#$00#$2E#$72#$64#$61#$74#$61#$00#$00#$1C#$10#$00#$00#$54#$00#$00#$00#$2E#$72#$64#$61#$74#$61#$24#$7A+
    #$7A#$7A#$64#$62#$67#$00#$00#$00#$00#$20#$00#$00#$10#$00#$00#$00#$2E#$72#$73#$72#$63#$24#$30#$31#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00+
    #$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00;

 

[DFenix 0]

1 hour ago, Anders Melander said:

No.

A resource module is just a PE file (a DLL) with a resource section but without any code.

 

That's how I use it too.

I use Bamboo with the following config for the BTM task (XXX is the target project name). The target is a 64-bit exe.

• Executable: c:\Tools\Better Translation Manager\amResourceModuleBuilder.exe
• Argument: "${bamboo.build.working.directory}\translation\XXX.xlat" -v -b -n:0 "-s:${bamboo.build.working.directory}\bin\XXX.exe" "-y:${bamboo.build.working.directory}\bin\XXX.drc" "-o:${bamboo.build.working.directory}\bin"

 

What do you mean by "my own resource project format."?

Thanks for the info and clarification.

 

I mean that I have a similar xlat project file, but with other text format and all information about translations strings. So, I would like to keep it or transform it to the .xlat format to build it in a resource dll, other option would be to modify and adapt the amResourceModuleBuilder to read my project and build it, of course if that is possible and permissible.

Thanks.

[Anders Melander 1782]

17 minutes ago, DFenix said:

I mean that I have a similar xlat project file, but with other text format and all information about translations strings.

I see. Can you reveal what tool was used to produce that format? Maybe I can make an importer for it.

 

19 minutes ago, DFenix said:

So, I would like to keep it or transform it to the .xlat format to build it in a resource dll, other option would be to modify and adapt the amResourceModuleBuilder to read my project and build it, of course if that is possible and permissible.

It's open source so you can do whatever you like with it.

 

If you prefer to keep your existing format the easiest approach would probably be to modify a copy of the amLocalization.Persistence unit and then alter the TLocalizationCommandLineTool.LoadFromFile method in the amLocalization.CommandLine unit to use your own persistence class.

 

It should be relatively easy to extend the existing solution with support for different project file formats using either an internal or external plugin architecture [*] but I'm not sure when I will have time to add that.

 

*

Internal=You register a class to handle your format and recompile. Very easy to implement for me.

external=You build and register an external DLL which handles the format. Much more work as I would need to wrap much more stuff in interfaces.

[DFenix 0]

1 hour ago, Anders Melander said:

I see. Can you reveal what tool was used to produce that format? Maybe I can make an importer for it.

 

It's open source so you can do whatever you like with it.

 

If you prefer to keep your existing format the easiest approach would probably be to modify a copy of the amLocalization.Persistence unit and then alter the TLocalizationCommandLineTool.LoadFromFile method in the amLocalization.CommandLine unit to use your own persistence class.

 

It should be relatively easy to extend the existing solution with support for different project file formats using either an internal or external plugin architecture [*] but I'm not sure when I will have time to add that.

 

*

Internal=You register a class to handle your format and recompile. Very easy to implement for me.

external=You build and register an external DLL which handles the format. Much more work as I would need to wrap much more stuff in interfaces.

I have used my own format, with key-value pairs for original English string (key) and translated string (value)), I get the complete set of localizable strings from my source code, this info is added to the executables as a resource (.res) and Inside the source code, we have to call a translate function for a matching value for the key. If no value is found, the original English string is being used.

 

So, for now I am going to change my own system and use the standard translation system for Delphi projects.

 

Altrought, I think should be easy to transform our format to the .xlat format and build it as it is now. However, also I like the idea to extend the solution to support different project file formats using an internal system.

I will let you to know what approach I decide to follow.

Thanks.
 

[Anders Melander 1782]

2 minutes ago, DFenix said:

I have used my own format, with key-value pairs for original English string (key) and translated string (value)), I get the complete set of localizable strings from my source code, this info is added to the executables as a resource (.res) and Inside the source code, we have to call a translate function for a matching value for the key. If no value is found, the original English string is being used.

You might be able to use the existing CSV importer to import those into a project. Just specify "=" as the delimiter instead of ";"

[roynielsen2000@gmail.com 0]

Hi,

 

I'm testing the translation tool and may have encountered a problem with the commandline tool, it ignores the -n filename scheme paramterer ?

It doesn't matter if I use -n:1 or -n 1 (or 0 or 2 as the value), I always get the 3 letter extension for the translation files

 

c:\Program Files (x86)\Melander\Better Translation Manager>amResourceModuleBuilder.exe c:\PicassoSVN\local\Localization\Reception\Reception.xlat -b -v -o:c:\PicassoSVN\local\ExeFiles\emb\ -n 1
amTranslationManager resource module builder version 1.3.8055.21506

Loading project: Reception...
Project information:
  Source file    : c:\PicassoSVN\local\ExeFiles\Reception.exe
  Source Language: Locale=0409, Name=English (United States)
  Symbol file    : .\Reception.drc
  Target language: Translated=22.585, Locale=0406, Name=Danish (Denmark)
  Target language: Translated=11.844, Locale=041D, Name=Swedish (Sweden)
  Target language: Translated=11.266, Locale=0414, Name=Norwegian Bokmål (Norway)
  Modules        :    501
  Items          : 26.765
  Properties     : 33.866
Output folder: c:\PicassoSVN\local\ExeFiles\emb\
Building resource module for Danish (Denmark): Reception.DAN...
Building resource module for Swedish (Sweden): Reception.SVE...
Building resource module for Norwegian Bokmål (Norway): Reception.NOR...
Done

[Anders Melander 1782]

35 minutes ago, roynielsen2000@gmail.com said:

it ignores the -n filename scheme paramterer ?

Yes, that was a bug. I've just pushed a fix. Do you need me to upload a new build or can make one yourself?

 

P.S. Say hi to Arne for me.

[roynielsen2000@gmail.com 0]

3 minutes ago, Anders Melander said:

Yes, that was a bug. I've just pushed a fix. Do you need me to upload a new build or can make one yourself?

 

P.S. Say hi to Arne for me.

Please uplolad a new build 🙂

 

And I will say hi to Arne from you 🙂

 

[Anders Melander 1782]

36 minutes ago, roynielsen2000@gmail.com said:

Please uplolad a new build

my kbd just died so im typing w the on-screen kbd :-(

I'll get on it when that's resolved

Edited May 30, 2022 by Anders Melander

[Anders Melander 1782]

35 minutes ago, roynielsen2000@gmail.com said:

Please uplolad a new build

Here you go. Version 1.3.8185.25123: https://bitbucket.org/anders_melander/better-translation-manager/downloads/

 

[roynielsen2000@gmail.com 0]

Hi,

 

We would like to switch from Sisulizer to BTM, so we where thinking if there is someone who has already done that and if there are anything we need to have attention on ?

We think about doing it this way:

 

1. For each if our applications, export the Sisulizer translation to TMX format (is that the way to do it or is there a better way?)

2. Translate each application using BTM with the TMX file

 

Is there a better/easier way than this (we would like to reuse our translation as much as possible) ?

 

Sisulizer integrates the language files into the .exe files (SlMake.exe does this as far as I can tell), and the language files is then extracted when the .exe file is launched, so we will modify our build tool to create the language files and distribution tool to update the language files, so that shouldn't be a issue 

 

[roynielsen2000@gmail.com 0]

Hi,

 

I think I found a bug:

 

I have export a Sisulizer file to tmx format with Danish, Swedish, Norwegian (Nynorsk) + 2 other languages

Now when adding Norwegian Nynorsk to BTM and try to "Translate from TM" nothing is translated, but if I add Norwegian (Bokmål) as a language and translate, then I get translation as expected

I think it is a BTM problem because in the tmx file it is the countrycode "nn" which from what I found i Norwegian Nynorsk (and nb is Norwegian Bokmål)

[Anders Melander 1782]

3 hours ago, roynielsen2000@gmail.com said:

1. For each if our applications, export the Sisulizer translation to TMX format (is that the way to do it or is there a better way?)

2. Translate each application using BTM with the TMX file

 

Is there a better/easier way than this (we would like to reuse our translation as much as possible) ?

That's certainly one way to do it but since TMX files are meant for translation memory and what you really want to transfer is the actual translations it would be better to use the XLIFF format if you can make that work. Like everything else the OASIS organization has produced the XLIFF format is a bit fragile. The variant I have implemented support for is the one produced by Delphi's ETM export.

 

1. In Sisulizer export a language to XLIFF. As far as I know it can only export the translations for a single language at a time.
2. In BTM make sure the language being imported is among the target languages. Edit: It seems the importer takes care of this automatically.
   
3. Import the XLIFF file.
   

Because the XLIFF importer is tailored to handle the XLIFF files produced by ETM it has some some restrictions which may cause it to barf on other sources. For example it requires text strings to be quoted and it doesn't handle text with attributes (encoded in the XLIFF as sub XML-nodes). If it can't handle the XLIFF produced by Sisulizer then you can either try TMX or you can mail me one of the XLIFF files and I can see if I can tweak the importer to handle them.

 

If you do go the TMX way I suggest you start each import with an empty translation memory (just delete/move the TranslationMemory.dat).

Edited June 8, 2022 by Anders Melander

[Anders Melander 1782]

20 minutes ago, roynielsen2000@gmail.com said:

Now when adding Norwegian Nynorsk to BTM and try to "Translate from TM" nothing is translated, but if I add Norwegian (Bokmål) as a language and translate, then I get translation as expected

Can you mail me the TMX file (zipped)?

[Anders Melander 1782]

9 hours ago, roynielsen2000@gmail.com said:

Now when adding Norwegian Nynorsk to BTM and try to "Translate from TM" nothing is translated, but if I add Norwegian (Bokmål) as a language and translate, then I get translation as expected

I think I've found the cause of this. This is actually a "funny" bug. Funny because I've done much of my testing with Norwegian, Bokmål which, it turns out, is one of the only locales that doesn't make the bug obvious.

 

When identifying the languages I first search my locale database for the RFC 4646 language-region code.
The RFC 4646 code for Nynorsk is nn-NO and for Bokmål it is nb-NO.

 

If I fail to locate the locale based on the RFC 4646 code then I delete the last part of the RFC 4646 language-region which leaves me with the ISO639-1 language code. I then search for the ISO639-1 code.
The ISO639-1 code for Nynorsk is nn and for Bokmål it is nb. There's also a code for the Norsk macro language: no...

 

Since an ISO639-1 code can map to many different locales (e.g. en -> en-US, en-GB, en-AU) I then find the "primary" locale for the language and use that. What can possibly go wrong...

 

Well, the bug is that instead of deleting the last part of the RFC 4646 I deleted the first part so nn-NO becomes NO and the primary locale for NO is nb-NO = Bokmål.
I'll fix that but the question is why I failed to find nn-NO in the first place. Hmm. Maybe there's another bug I haven't spotted...

[Anders Melander 1782]

31 minutes ago, Anders Melander said:

Maybe there's another bug I haven't spotted...

Found it. The Windows LCID for nn-NO is LANG_NORWEGIAN,SUBLANG_NORWEGIAN_NYNORSK and for nb-NO it's LANG_NORWEGIAN, SUBLANG_NORWEGIAN_BOKMAL so the LCID considers them two dialects of the same language. I guess I should stop using LCIDs as a the primary identifier for locales.

[roynielsen2000@gmail.com 0]

17 hours ago, Anders Melander said:

Can you mail me the TMX file (zipped)?

Hi Anders,

 

Do you still need the tmx file ? I can see you seem to have found the problem 

[Anders Melander 1782]

2 hours ago, roynielsen2000@gmail.com said:

Do you still need the tmx file ? I can see you seem to have found the problem

Yes please. I'd like to first reproduce and then verify the solution with your actual data.

[Anders Melander 1782]

@roynielsen2000@gmail.com I've reproduced the problem with your file.
For now you can work around the problem by editing the TMX file and replacing all lang="nn" with lang="nn-NO".

[Anders Melander 1782]

@roynielsen2000@gmail.com The nn/nn-NO TMX issue has been resolved. I have not yet done anything with regards to handling Sisulizer's XLIFF files.

New version uploaded.

Edited June 12, 2022 by Anders Melander