[Exist-open] I18n and 'Accept-Language' header?

[Tony Graham]

http://exist-db.org/exist/apps/demo/examples/special/i18n-docs.html#usage
states:

----
The language to use for internationalization can be chosen in various ways

- via http parameter 'lang', e.q http://exist/index.html?lang=de
- as xquery parameter $selectedLang if the i18n module is called
directly
- xml:lang attribute on the root node of the markup to process
----

Why doesn't the i18n module also have a fourth (or possibly
two-and-a-halfth) alternative of finding the language from the HTTP
'Accept-Language' header, e.g.:

----
Accept-Language: ja,en;q=0.7,en-GB;q=0.3
----

?

I could, of course, modify my app to start passing around a 'lang'
parameter, but I'm wondering why I should have to instead of having the
option of defaulting to using the browser's opinion of the language to use.

Regards,


Tony Graham.

[Wolfgang Meier]

Post by Tony Graham
Why doesn't the i18n module also have a fourth (or possibly
two-and-a-halfth) alternative of finding the language from the HTTP

There’s a slightly extended version of the i18n module below, which checks the Accept-Language header:

http://gitlab.exist-db.org/tei-publisher/tei-publisher-app/blob/master/modules/lib/i18n.xql

I planned to either move this back to demo-apps or - preferably - we should extract everything into a separate i18 package to be used by all apps.

Wolfgang

[Tony Graham]

Post by Wolfgang Meier

Post by Tony Graham
Why doesn't the i18n module also have a fourth (or possibly
two-and-a-halfth) alternative of finding the language from the HTTP

There’s a slightly extended version of the i18n module below, which
http://gitlab.exist-db.org/tei-publisher/tei-publisher-app/blob/master/modules/lib/i18n.xql

Thanks. However, that could now do with the typo fixes from
https://github.com/eXist-db/demo-apps/pull/22

I appreciate that this version can return arbitrary nodes rather than
just one text node, since I have some text to translate that currently
has a <br/> in the middle of it.

Can you explain basing the language selection on @xml:lang? I can't
work out when that would be useful.

If the preferred method of setting the language is a 'lang' HTTP
parameter, how do you set the parameter in @href in template pages such
as
https://github.com/wolfgangmm/eXide/blob/develop/templates/existdb/templates/page.html?

Post by Wolfgang Meier
I planned to either move this back to demo-apps or - preferably - we
should extract everything into a separate i18 package to be used by
all apps.

A separate package would suit me better, I think.

Regards,


Tony Graham.

[Tony Graham]

On 20/05/2017 08:48, Tony Graham wrote:
...

Post by Tony Graham
work out when that would be useful.

?

Post by Tony Graham
If the preferred method of setting the language is a 'lang' HTTP
such as
https://github.com/wolfgangmm/eXide/blob/develop/templates/existdb/templates/page.html?

Currently I'm doing some application-specific lookup in my version of
i18n:getSelectedLanguage() when there is no 'lang' HTTP parameter.

At XML London, Adam suggested the possibility of storing the language as
an attribute of the session. Is that something that could become part
of a standard eXist-db i18n module?

If that is useful, would it also be useful to have another session
attribute that is a map of language codes and the catalogue file to use
for each language code? (Strictly speaking, it would be better to be a
sequence of catalogue files to be tried in sequence so that, e.g.,
'en-GB' could fall back to the 'en' catalogue file or an application
could populate the value with catalogue files of decreasing specificity.)

Presumably the default language could also be a session attribute.

I would assume that the application would populate these session
attributes and that the i18n module would just use them if they exist.

Regards,


Tony Graham.