GetUILanguages / SetCurrentUILang - when working with .manifest SOLVED

[zarkogajic]

Hi support,

How should the SetCurrentUILang work when using .manifest for registration free usage?

I've tested and confirmed with FullDemo that there are no languages when Inst.GetUILanguages is called.

When working with the registered COM server - languages are listed - from where ?!?

p.s.
I see "Common\Languages" folders are mentioned here: viewtopic.php?f=66&t=32629&p=133702&hil ... ng#p133702

I thought I could get some language files, if they are needed, from https://www.pdf-xchange.com/langua ... nge-editor but this downloads a file that wants to install itself to Editor (and when it does there's still no "Languages" folder under "Common").

-žarko

[BigMike]

The language packs, which you can download are simple zip archives. You can extract the files manually to any location you like.
I don't know about the SDK, but for the standard installation, the language files should be located in
C:\Program Files\Common Files\Tracker Software\Common\Languages (%CommonProgramFiles%\Tracker Software\Common\Languages).
older versions used "C:\Program Files\Tracker Software\Common\Languages".

[zarkogajic]

Hi,

Thanks, this helped.

Anyhow, still, sdk related, the question: why does it work when not using the .manifest?


-žarko

[zarkogajic]

Hi support,

One more related question:

I've tried using AddDefaultTranslationData to load the translation from the file (xml).

This works, however, the UI language is switched to last added translation data.

And then calling SetCurrentUILang does nothing actually.

I could "fix" this by calling AddDefaultTranslationData each time when language needs to be changed - but I'm not sure that is the proper way - how it was envisioned / designed ?

p.s.
I'm trying to avoid the need to have "Strings.lng-Lng.xcl" in \Common\Languages folder. I'm storing the .xcl's as a resource in my exe and extracting as a resource into an Istream.

-ž

[zarkogajic]

Support?

-ž

[Sasha - Tracker Dev Team]

Hello zarkogajic,

Will forward this to Vasyl. Probably he can tell more.

Cheers,
Alex

[Vasyl-Tracker Dev Team]

Hi žarko.

The AddDefaultTranslationData adds all your primary(default) built-in strings from the specified xml to the application's table of primary strings.
Each primary(default) string is the pair like { uniqueStrID, "<text>" }. For example:

Code: Select all

<Language eName="English" lName="English" code="-" R2L="false"/>
<Module name="PDFXEditor" namespace=""/>
       <Strings>
             ...
             <text id=str1'>First</text>
             <text id='str2'>Second</text>
             ...
      </Strings>
...

such two rows declare two strings with str1 and str2 IDs and corresponding english text.
So, after adding such strings to the global application's string-registry via AddDefaultTranslationData, you will be able to use them in runtime:

Code: Select all

combo.InsertItem("$$$.str1"); // adds the "First"
combo.InsertItem("$$$.str2"); // adds the "Second"
or
combo.InsertItem(Inst.GetLocalStr("str1")); // adds the "First"
combo.InsertItem(Inst.GetLocalStr("str2")); // adds the "Second"

// ***first method is better because such strings will be re-translated automatically when user changed the UI language
[/code]

Then if you want to make your strings localizable - you need to put some additional .xcl files to the ./Common/Languages folder. Each xcl-file must contain a translation for certain strings (the target language is specified in this file). For example:

./Common/Languages/abcd.de-DE.xcl

Code: Select all

...
<Language eName="German (Germany)" lName="Deutsch" code="de-DE" R2L="false"/>
<Module name="PDFXEditor" namespace="" />
	<Strings>
            ... 
             <text id=str1'>Erste</text>
             <text id='str2'>Zweite</text>
            ...
	<Strings>
 ....

./Common/Languages/abcd.fr-FR.xcl

Code: Select all

...
<Language eName="French (France)" lName="Français" code="fr-FR" R2L="false"/>
<Module name="PDFXEditor" namespace="" />
	<Strings>
            ... 
             <text id=str1'>Premier</text>
             <text id='str2'>Deuxième</text>
            ...
	<Strings>
 ....

And finally:

Code: Select all

Inst.AddDefaultTranslationData(streamWithMyPrimaryStrings); // call it once only in the block of initializations
....
....
....
combo.InsertItem("$$$.str1"); // adds the "First"
combo.InsertItem("$$$.str2"); // adds the "Second"
....
....
Inst.SetCurrentUILang("de-DE");
// > now combo contains: 
// Erste
// Zweite
....
....
Inst.SetCurrentUILang("fr-FR");
// > now combo contains: 
// Premier
// Deuxième

HTH.

[zarkogajic]

Hi Vasyl,

Thanks.

It seems I'm then exploiting AddDefaultTranslationData to change default strings (and not add my own)

Is there any way to avoid the requirement to have non-english translations (of default English strings) be placed under "./Common/Languages/" on the file system?

Why are languages available when working with the registered dll and not when using .manifest?

What I'm doing at the moment and it seems to work: storing XCLs inside my exe as a resource. I've simply used the EN xcl from resources.dat and for other languages I've downloaded xcls. Then, when at run-time I want to change the UI language I'm extracting xcls to IStream and using it with AddDefaultTranslationData, then calling SetCurrentUILang.

Note that xcls contain default strings only - I'm not adding my own.

This seems to work, BUT I'm obviously calling AddDefaultTranslationData, for the same language (even for EN), multiple times. Example: switching languages from standard EN to FR, then EN, then FR again. This means I would be calling AddDefaultTranslationData for FR two times. How bad is that? I mean there are no errors and it does not seem to break something - but....

-ž

[Sasha - Tracker Dev Team]

Hello zarkogajic,

As Vasyl said, the AddDefaultTranslationData should only be called once, as it will spam a translation data vector with the same values again and again.
Basically, you will need to call the SetCurrentUILang, not the AddDefaultTranslationData every time.

Cheers,
Alex

[zarkogajic]

Hi Alex,

Each primary (default) string is the pair like { uniqueStrID, "<text>" }

What happens internally when I call AddDefaultTranslationData with the same "uniqueStrID" for the same language two times?

It will not be doubled in the application's table of primary strings. Correct?

-ž

[Vasyl-Tracker Dev Team]

What happens internally when I call AddDefaultTranslationData with the same "uniqueStrID" for the same language two times?

It replaces text for the existing strings with the same uniqueStrID.

[zarkogajic]

Thanks Vasyl,

How about:

Why are languages available when working with the registered dll and not when using .manifest?

-ž

[Vasyl-Tracker Dev Team]

Strange, it should work well in both cases.. In case with the .manifest - have you the non-empty Common/Languages folder in the same location that contains the PDFXEditCore.x64/.x86.dll (that used by your app via manifest)? Can you double check by ProcessExplorer the location of PDFXEditCore module actually used by your app?

[zarkogajic]

Hi Vasyl,

In the FullDemo sample app there's no ".\Commom\Languages" folder.

When building using .manifest the drop down to pick the language does *not* get populated.

When building with the registered (ole server) dll - languages *are* populated (?? from where)!

You should be able to reproduce this.

-ž

[Sasha - Tracker Dev Team]

Hello zarkogajic,

As Vasyl said - you will need the ".\Commom\Languages" near the dll that's being used in the manifest - then everything will work for you. When you are using the registered dll, probably, you are using it from the installed SDK/Editor folder - there the ".\Commom\Languages" folder is present thus everything is working.

Cheers,
Alex

[zarkogajic]

Hi Alex,

Yes, that's it, thanks - there's ".\Commom\Languages" where EditorSDK is installed. Sorry, I do not see how I missed to see it.

-ž

[Sasha - Tracker Dev Team]