Trace language selection in FR?

Afraid I must bother the list with a repeat question (old question).

I'm trying to convince Form Runner it should use the Swedish language. A long time ago you could turn on debug flags to trace the language selection process. Now I've turned everything on in log4j.xml. Lots of output, but no sign of language selection. Any help to clear out my mental mist is appreciated. I'm still in Orbeon 4.4.

/Hakan

I fear that right now, there is no way to trace that, except with a debugger!

Did you set the default language to be Swedish?

-Erik

This is in my properties-local.xml:

  <property as="xs:string"
	    name="oxf.fr.available-languages" value="en fr sv"/>
  <property as="xs:string"
	    name="oxf.fr.default-language.*.*" value="sv"/>

Did I forget anything?

/Hakan

Hi Hakan,

Also try setting:

    <property as="xs:string"
     name="oxf.fr.available-languages.*.*" value="en fr sv"/>

The property without the .*.* applies only to "global pages", that are not tied to a specific form. For now, I think only the Form Runner home page falls in that category, but there could be other pages in the future.

Also, if you don't see the default language being picked, try starting a new session, as Form Runner remembers the current language in the session.

You'll let us know if this does it for you.

Alex

Well, a small success by narrowing available languages. It seems that if English is available the FR picks English, no matter what. Here is a snippet of my properties-local just in case I got something wrong.

  <property as="xs:string"
	    name="oxf.fr.available-languages.*.*" value="fr de sv"/>
  <property as="xs:string"
	    name="oxf.fr.available-languages" value="fr de sv"/>
  <property as="xs:string"
	    name="oxf.fr.default-language.*.*" value="sv"/>

With this setting the FR picks Swedish. Problem is, I suspect we can't do without English. I tried with Firefox with Swedish localization, and Chrome with US-English localization. Both work.

A few impressions I collected on the way, not necessarily correct:
-- I can't see that adding "?fr-language=sv" (or ...=fr) ever has any effect on language selection
-- The language selection has moved to Scala. The new logic does not consider the language of the form. In earlier releases the language of the form was a major factor, even if the exact definition was a little uncertain.

/Hakan

Hi Hakan,

I'm not sure to understand what isn't working. You're saying that "It seems that if English is available the FR picks English, no matter what.", but then "With this setting the FR picks Swedish.". So does it pick your default language, as expected? If not, have you tried clearing the JSESSIONID (or similar) in the browser, to start a new session?

- ?fr-language=sv correctly changes the language for me. It has the same effect as the user clicking on that language.
- What do you mean by "does not consider the language of the form"? Only the languages available for the current form should be shown. (I.e. users shouldn't be able to select a language in which the current form isn't available.)

Alex

I tried different sets of "available-languages" (i.e. property values). If "en" is among those languages the Form Runner picks English for its messages even though the default language is Swedish (sv). It does so even if I add ?fr-language=sv to the request url. The language of the form is Swedish which means that section headings, hints, etc. are displayed in Swedish, Form Runner messages in English. I simply cannot make Form Runner pick anything but English if "en" occurs in "available-languages".

The XML snippet defines French, German and Swedish as available languages. In this case the Form Runner picks Swedish, the default language. As a side issue I cannot make it pick French, for instance, by adding ?fr-language=fr to the request url. (That's just an experiment to find out how language selection works, not necessarily a real use case.)

As a special case, if "available-languages" is only "sv" then the Form Runner picks Swedish.

The behaviour is the same for the two browsers I use for testing, Firefox with Swedish localization, and Chromium with US English localization.

Unfortunately I don't understand what you mean by "clicking on the language". Is there a visible language selection in the Form Runner gui? I know it exists in Form Builder. This passage of my previous post is just a guess of mine after reading Scala code, you may ignore it. I didn't see that Form Runner uses the form language as a factor in language selection, but  chances are I overlooked something.

It would be valuable to re-implement a way to get a trace from Form Runner to follow the language selection process.

/Håkan

My colleague urges me to clarify the previous post. Here we go. If "en" occurs in "available-languages" I am unable to make Form Runner select Swedish, the default language. The only way to make it select Swedish is to remove "en" from "available-languages". Other "available-languages", like "fr" and "de", may be present and do not prevent the Form Runner from selecting Swedish, the default language.

/Hakan

Hi Hakan,

By default, there is a language selector in Form Runner, at the top right of the form. You can see it in the screenshot below. So you seem to have 2 problems:

1. If English is in available, Form Runner still uses resources in English instead of in the current language.
2. Form Runner doesn't pick your default language.

For #1, I've created a form (form.xml) in 4 languages, en fr de sv, and set the following property:

    <property as="xs:string"
     name="oxf.fr.available-languages.*.*" value="en fr de sv"/>

I select Swedish ("Svenska"), submit the form, and the message for "Missing or incorrect value" shows in Swedish, as expected, which seems different than what you describe in #1.



For #2, using the same form, I've also set the following property:

    <property as="xs:string"
     name="oxf.fr.default-language.*.*" value="sv"/>

If I reload the form, it shows in whatever language I selected earlier. But if I clear the JSESSIONID, and reload the page, now Swedish is picked. Are you seeing something different, or testing this differently? Now if I add ?fr-language=fr to the URL, the language switches to French, as if the user had clicked on "Français" in the language selection widget.

While testing this I've hit an issue where if a message is shown in the error summary, and you switch languages, the language of the message doesn't update right away. I've created bug for this:

https://github.com/orbeon/orbeon-forms/issues/1743

Alex

Many thanks for this comprehensive post and example. This will take me a while, but I'll be back with results. /Hakan

Hi Hakan,

Sounds good; you'll let us know!

Alex

Your example was illuminating.

There were moments of perplexity, because my experience was consistent and reproducible but different from yours in the following ways: (1) English was chosen above the default language. (2) Form Runner did not show a language selector (the one beside the validation tick symbol in the form header). (3) The "?fr-language=sv" request parameter had no effect.

I tried with Orbeon 4.4 and 4.5 and two different browsers.

The answer, it seems, is the language of the form. We create forms in Form Builder using the default language, English. The forms then go through a filter that changes some "xml:lang" attributes from "en" to "sv". In short, we try to create Swedish forms without doing a Form Builder localization.

When I hand edited the form to add English resources I got the experience you described. All three issues above were solved.

My impression (right or wrong) is that the language selection logic in Form Runner has changed somewhere along the road. I guess it checks the various form resources to make up its mind about the languages present in the form.

As for our application, we should simply comply with the new logic. New questions arise:

(a) Why does the Form Builder tool impose its own localization on the form being built? I think the two languages (tool and form, respectively) are independent. In a multi-language environment it is very likely that a form designer prefers to use Form Builder in one and the same language always. Resources in other languages would probably be delivered from a translation service. The form designer would ideally copy/paste resources into the multi-language form without switching Form Builder localization.

(b) How does Form Runner determine the language of a form? Is the process documented?

We currently operate in a single language, so question (a) is mainly theoretical from our point of view. Question (b), on the other hand, has practical implications.

/Hakan

Hi Hakan,

(a) Yes, the set of languages available for Form Builder and your form, as well the current language for Form Builder and your form can all be completely different. This is why you have 2 language selectors in Form Builder:



In this example:

1. Form Builder is available in English, French, Italian, German, Spanish.
2. The current language for Form Builder is French.
3. The form is available in French, Swedish, German, and English.
4. The current language for the form is German.

1+2 will have no impact on the form at runtime; they only impact the UI of Form Builder itself, and thus only matter to the form author. Only 3+4 have matter for the form at runtime.

Right now we don't support loading form resources from a service; it is expected that the form will be localized within Form Builder. However, since all the resources are stored in a single instance <xf:instance id="fr-form-resources">, if you want to have a third party do the localization, you can imagine just sending them that piece of XML, asking them to localize it, and then pasting it back in Form Builder. Of course, you'll need to make sure not to modify the form in the meantime (or manually resolve possible conflicts).

(b) Right now, this isn't documented, other than through FormRunnerLang.scala ;) (link below). In essence it tries to get the current language from the following sources, and stops when it finds one (i.e. earlier items in this list have the priority): the Liferay header, a request parameter, the session, the default language defined by properties for the current app/form.

https://github.com/orbeon/orbeon-forms/blob/tag-release-4.5.1-ce/src/main/scala/org/orbeon/oxf/fr/FormRunnerLang.scala#L111

Does this make sense?

Alex

Alex, thanks for a very complete response. It seems I was calling for something that's already there. And Scala isn't too bad for documentation if it's well written:)
/Hakan

German language classes in pune


Blogs are particularly precise due to the fact they’re regularly thoughtfully written and provide you perception on how to learn.

But there’s one problem.

There is too a whole lot information. It can be a Herculean project to kind the wheat from the chaff and locate the actually top notch resources.

Fear not. If you’re getting to know German, we’ve saved you from thousands of donkey work via studying and reviewing some of the first-rate German language blogs that are out there.

Until now possibly you’ve been targeted on getting to know German crucial vocabulary, appropriate pronunciation, and even a few famous slang words.