Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Location names are not directly translatable.  This document describes an approach to work around this limitation.  It allows you to arbitrarily customize the display of locations or any other fixture in your app.

Multiple choice or checkbox lookup table questions typically operate on a fixture instance, but you don't have very much control.  The technique described here instead creates a "nodeset" using a repeat group with a model iteration query, and then uses that for the lookup table question.  This way, you can define whatever properties you need in the nodeset for reference in the lookup table question.

Storing Location Translations

The first thing you need for this to work is stored translations.  You can define custom location fields for the name in each supported language, for example:

  • name-en

  • name-hin

  • name-es

Then edit your locations to populate these fields.  This information will now be available to access in your application.

Referencing the current language

This process is described in the page on Using Lookup Tables with Multiple Languages.  If you set up the lang-code question as described there, you should be able to use jr:itext('lang-code-label') to refer to the current language.

Setting up a nodeset

Add a new repeat group, and under the "Advanced" section, set the Model Iteration ID Query to "instance('locations')/locations/location/@id".  This will make one iteration of the repeat group for each location in your project. You can add a filter here if you like, or you can filter the expression later, in your lookup table question.  Set the Instance ID to "locations", and the Instance URI to "jr://fixture/locations" to make sure the instance is available in the form.

Inside this repeat group, add hidden values for whatever you may need to reference.  The location id will be made available by virtue of the Model Iteration ID Query.  Here you can make a translated "name" field - just add a hidden value which selects the appropriate field for the active language:

cond(jr:itext('lang-code-label') = 'es', instance('locations')/locations/location[@id = ../@id]/location_data/name-es,
jr:itext('lang-code-label') = 'en', instance('locations')/locations/location[@id = ../@id]/location_data/name-en,
jr:itext('lang-code-label') = 'hin', instance('locations')/locations/location[@id = ../@id]/location_data/name-hin,
instance('locations')/locations/location[@id = ../@id]/name)

Note that you could do whatever you wanted here to decide how to display the location - you could reference the location's state, or a calculated property elsewhere in the form, for instance.

Setting up the Lookup Table question

Now that you have a suitable nodeset, you can set up a lookup table to reference it.  Add a new lookup table question and edit the lookup table.  Drag the repeat group used to make your nodeset into the "Query Expression" field.  It should look something like "/data/locations/item" (*Note: it must start with "/data/". The #form/ syntax will throw an error.)  Leave the Instance ID and Instance URI fields blank.  Then set the Value Field to "@id", and the Display Text Field to "name", or whatever field in your nodeset you want to display.  That's it!  Your lookup table question should now use the nodeset described above, with translated names.

  • No labels