This discussion is archived
6 Replies Latest reply: Dec 11, 2006 1:09 AM by 135285 RSS

Language setting of browser and Application Primary Language

135285 Oracle ACE
Currently Being Moderated
Hi,

my browser is currently set to German, that's why the APEX builder is also displayed in German. Brrr, I like development environments when they are not displayed in English - sometimes you don't understand this translations :-)

But my problem now is that I have created an application and set the Application Primary Language to English (en).

I would now assume that all the text APEX is creating during wizard actions will be created in the Application Primary Language and not in the language the browser is currently set to. But all the text is created in the browser language!!!

I think that's not a good behavior, because if you have a multi user/multi country development, the developers have to change there browser settings so that we get a consistent application. But to archive that I have set the primary language for the application.

Patrick
------------------------------------------------------------------------------------
Check out my APEX-blog: http://inside-apex.blogspot.com
  • 1. Re: Language setting of browser and Application Primary Language
    60437 Employee ACE
    Currently Being Moderated
    Patrick,

    A very esoteric point.
    But to archive that..
    ..achieve that..?

    So if your application's primary language is Estonian and you are running the Builder with your browser set to English, German, or French, the resulting strings should be what?

    How about text created by the wizards that let you create pages before you've selected the primary language, when you are creating a new application?

    Scott
  • 2. Re: Language setting of browser and Application Primary Language
    135285 Oracle ACE
    Currently Being Moderated
    Hi Scott,

    I know that NLS stuff is sometimes a really esoteric stuff :-)
    But to archive that..
    ..achieve that..?
    Sorry you are right, should be achieve. Need more practice writing in English.
    So if your application's primary language is Estonian and you are running the Builder
    with your browser set to English, German, or French, the resulting strings should be what?
    The resulting "defaults" strings which are displayed/used in the wizards should be Estonian, because that's my primary language of the application. Does it really make sense to show them in English/German, ...? Because the result language of the application should be Estonian.
    How about text created by the wizards that let you create pages before you've selected
    the primary language, when you are creating a new application?
    The builder is no genius (or not yet ;-) ), so that's up to the developers when they are changing the primary language during development.

    But a suggestion which just came into my mind. Why does the builder/wizard not use substitution strings (eg. #APPLY_CHANGES#, #NO_DATA_FOUND#) for this type of default text instead?

    This would help to unify text through all pages. And in the case if the users ask development to change these default texts to something else (eg. they don't like apply changes, they just want to have save), it would be a piece of cake to do that.

    It would also improve quality, because the developers don't have to change the text from now on all the time. Based on my experience, they will forget it half of the time... :-)

    Wouldn't it help to translate the application too? And to reference our above example again when they change the primary language, just a few substitution strings would have to be translated...

    It's just a suggestion based on my experience developing multilingual applications.

    Patrick
    ------------------------------------------------------------------------------------
    Check out my APEX-blog: http://inside-apex.blogspot.com
  • 3. Re: Language setting of browser and Application Primary Language
    60437 Employee ACE
    Currently Being Moderated
    Patrick,
    The resulting "defaults" strings which are displayed/used in the wizards should be Estonian, because that's my primary language of the application. Does it really make sense to show them in English/German, ...? Because the result language of the application should be Estonian.
    A) And how exactly will the Builder obtain the Estonian translation of these strings or of the translation of these strings into any of the hundreds of other languages we know nothing about?

    I think the answer is that the Builder should maintain an awareness of the language setting of the application being developed. During the generation of possibly translatable text, the wizards should use a translated message for that text/language if: a) the language is one of the ten languages in which we make the Builder application available, and b) the developer has installed that "language version" of the Builder application (even if they are running a different language version at the time of text generation). If either condition does not hold, then the text should be generated in the Builder's primary language (en-us).
    The builder is no genius (or not yet ;-) ), so that's up to the developers when they are changing the primary language during development.
    B) I don't understand your point (what is up to the developers?). The point I was trying to make was that even if we concede that generated text from the Builder should ideally be in the language that is the current primary language setting of the application being developed, the Builder would not be able to make that accommodation during the execution of the portion of the Create Application wizard that creates pages (with generated text in some language) because this occurs beore the language selection is made. Of course, the answer is that the Create Application wizard should be changed to allow the language to be selected before any text can be generated. Wizards would then be able to generate text in the appropriate language according to the rules proposed in (A).
    Why does the builder/wizard not use substitution strings (eg. #APPLY_CHANGES#, #NO_DATA_FOUND#) for this type of default text instead?
    This would result in "code" in areas of the metadata from which translation strings would be extracted into the XLIFF file. Translators would ignore this code so the ultimate translated application (and the primary) would need a repository in which to hold the desired text for each language to be supported and a method with which to dynamically lookup the translated text at runtime. I don't believe the current architecture supports this (apart from the fact that we don't currently do it this way) and I think the performance implications could be significant, but I could be mistaken on both points.
    Wouldn't it help to translate the application too?
    I don't understand this suggestion.

    Thanks for your input.

    Scott
  • 4. Re: Language setting of browser and Application Primary Language
    135285 Oracle ACE
    Currently Being Moderated
    Scott,

    point a) is exactly what i'm thinking about.
    B) I don't understand your point (what is up to the developers?).
    That they have to translate the pages which they have already created before changing the primary language to another language again. Seems that there was a miss understanding, because I thought about the case when the language is changed later on in the development process. You are right, the language setting should be somewhere at the beginning of the create application wizard.
    would need a repository in which to hold the desired text for each language [...]
    a method with which to dynamically lookup the translated text at runtime. I don't
    believe the current architecture supports this
    Why not use the "Application\Edit Attributes\Definition\Substitutions"? Aren't they intended for that? When the builder creates a new application, it should put all his "Wizard default texts" there, so that they can be changed for that application.

    About the dynamically lookup, with the above usage of global substitutions, nothing has to be changed, because APEX is already using this table to replace text in label if it is referenced with &SUBMIT.
    Wouldn't it help to translate the application too?
    I don't understand this suggestion.
    Haven't looked at the translation export yet, but wouldn't it be easier and faster for the translator if he just has to translate the few entries of the global substitutions, instead doing it for each button, ...?

    Patrick
    ------------------------------------------------------------------------------------
    Check out my APEX-blog: http://inside-apex.blogspot.com
  • 5. Re: Language setting of browser and Application Primary Language
    60437 Employee ACE
    Currently Being Moderated
    These remaining points are kind of secondary to the language/translation aspects. Centralizing common text used in many places sounds useful for ease-of-maintenance, it's just a question of the best implementation. For performance we might want to keep the text static wherever it is used and provide a UI to do mass updates (grid edit) on buttons, for example.
    Haven't looked at the translation export yet, but wouldn't it be easier and faster for the translator if he just has to translate the few entries of the global substitutions, instead doing it for each button, ...?
    I think the translation process is already optimized to make unnecessary the translation of the same string more than once by an external translation service.

    Scott
  • 6. Re: Language setting of browser and Application Primary Language
    135285 Oracle ACE
    Currently Being Moderated
    Hi Scott,

    thanks for taking the time to consider that!

    Patrick
    ------------------------------------------------------------------------------------
    Check out my APEX-blog: http://inside-apex.blogspot.com