designer multi-language setting

[Larelyn]

Hi,
The answer to my question below is probably a really basic, fundamental concept when using Profound UI in a multi-language setting, but I don't see anything in the documentation or forums to confirm my suspicions.

After running PUITRNSRC for a screen and restarting my designer session, I do see the multi-language settings have now become available. However, the language drop down from the Home section of the toolbar only shows en_US. I have confirmed with our administrator that we only have the ENU language set installed on our system.

Do I need to have secondary languages installed in my OS before I can properly begin building my translation database?

Thanks!

[David]

I'd recommend having a thorough read over this, if you haven't already:

http://www.profoundlogic.com/docs/displ ... lations%29

The translation features in the Designer do not use the IBM i language sets...

The language selection in the Designer is used only for development time. This controls what language you use to search for phrases when you are setting up widgets, and how they will appear to you in the Designer.

The language dropdown presents the choices of all the languages you have on file in the translation database. Since you have just run PUITRNSRC over your display, you have just English for now. Once translations are added in other languages, you will see them appear in the drop down.

However, as an English speaker, you would probably just use the one that you're using now in the Designer. The handling of the language code at runtime is different, see the section 'Runtime Processing' in the docs. This will default to a value based on the IBM i language code, and there is also a CL command you can use to set it explicitly if that does not work for you.

[Larelyn]

ah, I see my problem. I needed to run PUITRNSRC with LANG = es_ES to get where I needed to be. Total rookie mistake.

I've went into i Series navigator to change a field description for the es_ES language, then I changed my user langid to ESP in CHGUSRPRF. I updated and recompiled the program, then tried to give it a whirl. I get logged out and disconnected. I changed my user langid back to *sysval, and it works fine in English.

I would think this means that either "ESP" is not the right langid on my user account, or that I do indeed need the secondary language installed in my OS. Would this be correct?

Thanks!

[David]

Are the original display files in Spanish, or English?

You need to set the language code to be whatever language the constant strings are in the original display file. So 'en_US' for US/English or 'es_ES' for Spain/Spanish. This command does the following:

1. It finds the constant strings in the display file.

2. It checks the database to see if there is already an entry in the translation database for the string, using the language code specified on the command.

3. If the string is found, it replaces it in the display file with a reference to the translation database.

4. It can optionally write the translation database record,if the string is not found. It tags it using the language code specified on the command.

So, basically this can populate the translation database with all the constant strings in your displays, in the original language. And also modify the displays to reference the translation database instead of constant strings.

It does NOT actually translate text from one language to another -- you'd need a translator for that. What you would do is have the translator look at all the original language phrases in the database, and then add the translated versions to it.

[Larelyn]

Ah, it finally got through my head. The instructions said to run PUISETLANG for the job - I read as code. Running it as a command works. It did help that I figured out the LANG parameter for PUISETLANG is case sensitive.

In the future, would Profound consider adding a bit to the /profoundui/start program to help demonstrate the environment? I do understand my mistakes are very much at the newbie level, so perhaps it wouldn't be as useful.

Again, many thanks!

[David]

Glad we could help.

Sorry, I got hung up on PUITRNSRC and didn't read the rest of your previous post as thoroughly as I should have. For runtime, you have 2 options, basically. Using the example of Spain/Spanish, you could set the user language id to ESP. Our runtime processing would see this and then use the database language code 'es_ES' automatically. If it's not feasible for you to use the user language ids, you can just run the PUISETLANG command in the job instead.

As for not being able to sign in after changing your language identifier, I would think yes, this probably won't work well if the OS language pack is not installed.