1. What is the issue? Please be detailed.
How can the "default_language" setting be referenced/shown in a form variable?
3. What have you tried to fix the issue?
${default_language} gives an error.
As far as I know, there is currently no way to do this. Form definitions can query values in the "main instance" which defines the structure of submissions, but they can't query other elements outside of that, including translation definitions.
We've recently talked about better detection of the current language and language changes (e.g. in Jr:choice-name() not re-evaluated on form language change). This is thematically related. If it feels like functionality that's missing, consider changing the category of this post to "Ideas" and adding more detail on how you'd use this functionality.
Note that the rules for determining what language will actually be shown to users are a bit complex and aren't identical between Collect and Enketo (I've just added this to the differences doc). In both, default_language is the language that's shown the first time a form is opened. But if the user changes the language, that selection is remembered moving forward (and essentially becomes a local default). If no explicit default_language is set:
- Enketo: matches browser language if IANA language tags are used, otherwise the first language defined is an implicit default
- Collect: the first language defined is an implicit default
1 Like
Hi,
I would prefer that a default_language from the form settings should always dominate, even if different to the browser. Also, a language-code related alignment, e.g. Arabic (ar) should automtically dominate the alignment.
Small hint: Last line there is no more valid, as reference-table was removed 
This should be the case now. Setting a default language in Enketo - #10 by LN is where that change was made.
All of the same information is available in the template linked from that page. Do you see a way to make that clearer from the intro paragraph? Maybe it could say that the embedded reference table is now maintained in those documents.
I would simply remove the link there.
(There are some more places in the docs where the former link is empty now.)
Instead, maybe add a link to your differences doc in the new form template.
@LN. The following might better be moved to the template thread, please.
Sorry, I found the former ref-table easier for look-up, esp. for a quick search for appearances based on a question type. Whereas the template sheet is now - somehow - ordered by appearances, and needs to open Excel/Google app and the sheet, instead of a single web/text page.
How about embedding the reference tables directly in the page as in https://github.com/XLSForm/xlsform.github.io/pull/255? That makes them searchable with browser search without leaving the page.
There are two reasons it's ordered that way:
- it's easier to maintain because it better matches how we think of appearances in development and there are no duplicate mentions of each appearance
- the primary intended use is in the inline dropdown while authoring a form
The idea with having reference in the template is that reference is needed when authoring a form, which can happen in a template. Having to go visit a website for reference means context switching and can be very frustrating in an environment with intermittent connectivity.
If you don't like the template we've come up with, you could build your own and add the reference sheets (and it could just be blank survey/choices/settings/entities sheets with the reference added). Do you have a different context in which you're accessing this information?
Thanks, I am convinced now - and really appreciate the template! 
An idea would be to add (Excel) column filters to this table and the other ones in the template, incl. survey and choices sheet. This would easily allow to see/filter out all appearances for a type. We use those filters e.g. for checking names, labels or type-oriented changes.
Maybe, better extract the last discussion from here to the template thread?