localization utility bug ?

[dummy_decoy]

with CVI 8.5.0, i am using the UI localization utility to translate my panels into multiple languages. i performed two full translation, exported their respective  dictionnary and language file.

then i modified the UIR and wanted to edit my 2 translations. so i load the UIR into the localization utility, select "Import strings", make some changes into the first languages. then i select "Import strings" and import the dictionnary from the second language, and the strings displayed in the tools are NOT the ones i just loaded: they are still the strings of the first translation...is this normal ? did i miss something ?

now, after having modified the translations (by completely closing the tool between each translation), when i wanted to export the strings, the tool asked me if i want to replace or merge the existing file. i choose replace because, in theory, all strings from my panels are loaded into the tool so when saving, everything should be included as is... now if i re-import the strings, the tool asks me to resolve an ambiguity and no matter how many times i do resolve the ambiguity, the tool always asks me about this ambiguity... how do i make it remember my choice when resolving the ambiguity ?

as a side note, there is a lot of usability problems with this tool:

- no way to exports all strings including those not translated. i don't know every languages on earth and i want someone to perform some translations for me. as such, i'd like to export every strings in the panel, to send this person a text file to translate. (no, i refuse to send the uir file along with the localization utility and the CVI runtime... a text file is enough)

- no way to copy every strings from the default language into the localized language.

- it would be nice to perform multiple translations at the same time. this would allow to have hints from multiple languages when translating into less common languages. ultimately, the dictionnary file would contain every languages, which would suppress the multiple "import/export", thus avoiding to overwrite the wrong dictionnary file by mistake.

- missing a real help file...

[jared]

1) The 'Import Strings' takes the dictionary file, which is just a mapping from one string to another and is .uir file agnostic (see the Help! text), and checks all the untranslated strings in the currently loaded .uir in the utility to see if the default language string matches any strings in the dictionary file and if it does, then fills in the local language text with whatever strings is coupled with the default language string. In your case, after loading and translating the strings in the first language, all the strings are translated in the utility, so the 'Import Strings' will do nothing. It would be useful if the tool provided a way to clear all the local language strings, so that you could import the strings from a different language. We'll look into this. In the meantime, I think the easiest way to do it is to quit the utility and restart it, like you did.

2) I think you are confusing the purpose of the dictionary file and the language file. If you want to translate your .uir into 2 languages, you should have 2 dictionary files (.lwd) and 2 language files (.lwl). Like I said, the dictionary file is just a mapping of two strings. The dictionary file is useful if you have many .uir files to translate and you want to use the same translations in many .uir files. For example, you could build up a general purpose French dictionary file (french.lwd) and another German dictionary file (german.lwd). Then when you have another .uir file to translate (or just modify an existing .uir), you can do the following:

- load the .uir into the tool and import the strings from the french.lwd

- make any modifications/additions you need to

- export those new strings to the general purpose French dictionary (french.lwd)

- create the language file for that particular .uir file with File>>Export Language (I think it is useful to name it something like <UIRFileName>_french.lwl)

- exit the tool.

Then repeat the above steps for the German translation.

Your problem is that you created a single dictionary file for both languages. So your dictionary file had two translations for each string in the .uir, which is why it kept asking you to resolve the ambiguities.

3) The .lwd is just a text file (open it in CVI source editor). You could create a dictionary file (spanish.lwd) like the following....

[Translations]

1_D = "Hello"

1_L = <translate above string>

2_D = "World"

2_L = <translate above string>

and send it to somebody who knows Spanish and have him replace all the <translate above string>'s with the translation.

Hope this helps,

- jared

[dummy_decoy]

many thanks for the explanations. i know understand what i did wrong. i have indeed 2 dictionnary files, but i have 2 different english translations for the same french word depending on the context (the distinction is made on the label of the control: i bent a bit the french wording to save on space). now that i clearly understand how the "export/import strings" works, i do understand why i thought it was wrong. 

so now, i think the tool is missing an "import language" button, to start the translation exactly where i left it on the previous session. 

regarding the import string behavior and the lack of a "clear all" function: the help text is not very explicit regarding the fact that "import strings" only translates _untranslated_ strings. and regarding your third point: to send a dictionnary file like you described to someone, i would first need a dictionnary file, thus i need a way to create an empty one from the panel i load in the tool.

i am against a "blind" translation: a sentence has a meaning in one context that it has not in another context. i personally think that translating blind strings segments without considering the context (the panel, the purpose of the control, the action it triggers) in which it appears is erroneous. that's why i will not (and will never) have a single dictionnary file for all my translations, and that's why i thought the localization tool was buggy.