Language controller

[hannolans]

Would be great if we have a language controller, so a user can pick tours in a selected language.
For this we need:

• a language button in the tourselection view
• a view that shows all the available languages
• The available languages are all the languages in the system and/or aggregated from all the languages of all imported stops.
• If there is only one language available, we can hide the language button.

[hannolans]

@kjaebker The language controller is one step further than a localisation (issue 6). A language controller makes multilingual tours possible, whereas the localisation makes localised tours possible (tours and app in the local language).
@dlcerva are you planning to work on a language switcher? I experimented with a switch, and it worked, but only after restarting the app. It seems you need add a custom function in iOS to do language switching immediately. Also, the views should reload .

[dlferro]

Yes. Going forward, like you mentioned, we'll provide a language icon that will be displayed on the tour selection screen. Pressing it will provide the user with a modal and a listing of languages. Selecting one should reload the current view and once they dive in, it should be handled automatically.

[hannolans]

Great. For consistency, we could provide a table view with the languages instead of a modal. Additionally we can also change the UI language. We need to replace the function NSLocalizableString with a custom function because the function doesnt change on-the-fly", ie
http://aggressive-mediocrity.blogspot.nl/2010/03/custom-localization-system-for-your.html

[hannolans]

Any progress or news on code of a language selector? Should I submit a patch?

[dlferro]

This should be close. We discovered a issue that might arise utilizing localized bundles with core data and believe to have a solution to push forward.

Daniel Cervantes

On Feb 11, 2013, at 3:59 AM, "Hanno Lans" <[email protected]mailto:[email protected]> wrote:

Any progress or news on code of a language selector? Should I submit a patch?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-13372294..

---

This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact Daniel Cervantes by reply email and destroy all copies of the original message.

[hannolans]

Good to hear. What is your proposed solution? Adding an alternative function instead of NSLocalizableString to make live switching of the user interface possible? What do you mean with the issue utilizing localised bundles with core data? Is it possible to share the code to have a look on it?

[dlferro]

The issue stems with the fact that TAP CMS exports localized bundles. When the app initializes, it loads the TourML from users current language. If we were to change languages on the fly, the TourML wouldn't update because the tour id and timestamp would remain the same. To resolve this we're going to prefix the tour id with the current language.

Unfortunately I have the code in a stash at the moment while I work to add several other big updates. In essence though, on the Tour Selection view, we are placing a language icon on the top right. When clicked a language selection view will be modally displayed. When the user selects the language that should kick off the loading of the appropriate string localizations as well as reload the specified language in TourML.

[hannolans]

Ah. This doesn't happen when we have the language ids on a stop base and one tour.
If the CMS produces a multilingual tour, it should generate the stops in XML with language ids for all the elements that are language dependent and include that in one XML file as a multilingual tour.
See an example of multilanguages the TourML here: https://github.com/IMAmuseum/tourml/wiki/Multilingual-Support
I tried this and the app select the stops in the right language when switching.
As I interpret TourML correctly, there is no need to use localised bundles, but instead use the languageId in the XML.

[dlferro]

Correct. We've been going back and forth on which route to go since Apple recommends creating a localized bundle. Speaking with others, we might just go the route of using a single TourML doc. This will require us to update Tap CMS to use the this method of Bundle exporting.

[hannolans]

Cool. Yeah I think creating one tour with languageids in the tourml doc is the best approach.
I can imagine your considerations. Apple is not promoting multilingual apps with a language switch as it sees a device as a personal device and not as a device you can rent or share.
about Tap CMS, this is the related issue on the multilingual export of a tour: IMAmuseum/tap-cms#33