Language Switching

[james-rae]

Guts by @spencerwahl

The main goal of this post is to figure out how we're handling configs and languages intertwining. The way I see it there are two main options either the config that's loaded controls the language or the language controls what config is loaded...

Option 1: Config decides language

In this scenario if a map author wants to have separate configs per language they will load them as needed.

For example:

• Map is constructed with a config with lang: en , the language is set to english
• User clicks on some language switch button on the host page -> hostpage tells RAMP "here's a new config to load"
• RAMP sees lang: fr loads the new config and sets the language to french

If there is only one config for all languages then the map author can just call the regular language switch function. Related, the language switch function does not do anything to the config, it only alters the i18n locale.

Pros:

• There is no need to have multiple configs in a store
• Lang doesn't need to get involved with the config, it only needs to respond simple to "change to this language"

Cons:

• If we want to supply a language switch button in RAMP we'd need it to know what configs to pass etc.

Interesting points:

• If there is only one config (or there are multiple but they don't care about language), should the lang not be there? Alternatively a flag on the "new config" call that says ignore language.
  • For instance if you load a config with lang: en and then switch to french, then need to load a second config, if there's a lang in there it'll try to switch to that language.

Option 2: Language decides config

In this scenario the regular language call looks at available configs and switches to the one tied to the new language. Let's say the map author has given en: configA, fr: configB , switching to fr will load configB and switching to es will not have a config to switch to.

The map author would be required to provide the map configs before language switch, either in the constructor or maybe another function (registerConfig).

If there is only one config (or multiple but they don't care about language) then the map author shouldn't register configs to language codes, that way language will only control the translations and config switches (like normal in this scenario) won't alter the selected language.

Pros:

• Can have a simple default language switch button
• Configs are known up front, defaults can be applied ahead of time

Cons:

• Things get weird if there are multiple configs per language, which one gets registered, which one gets switched to if we allow multiple registers

Option 3: Both

In this scenario passing a new config changes the language, AND changing language switches the config if and only if theres a config for that language already available.

Pros:

• More flexible than either of the other options on their own
• Don't have to pass the en or fr config every time the language (and config) needs to switch

Cons:

• Language switching logic gets very weird if theres more than one config for a language, we would need one path that lets the language switch try to change the config and one that doesn't otherwise we'd get config switch -> language switch -> config switch....

Option 4: Neither (aka lazy)

Language switching only changes translations, config switching doesn't care about language ever.

Pros:

• We don't write any code

Cons:

• More API calls if configs and languages are connected at all
• No knowledge of previously used configs

Miscellaneous

As far as I know, most sites we make end up having a separate url for english and french, meaning that switching within the app doesn't make much sense. Do we care about a default language switch button/plugin?

Are there other options that I didn't consider?

[james-rae]

Group comment consensus:

In favour of not supporting the "user can change language mid-session and everything is preserved" use case. We think it's a lot of work for a scenario nobody will do in practical usage.

Things to keep in mind

• language menu on the hamburger menu to support when ramp is in a full page / full screen configuration
• ensure support via the En/Fr link on the canada.ca template
• consider the usecase where a bookmark is created in one language and sent to someone who wants to view the content in a different language

[james-rae]

Feedback from @spencerwahl

there is the use case that a Francophone is emailed or shared a pre-canned URL in English, and wants to change language so they can view the data in their native language.

If we just have the language switch affect UI then the map stays in the same state.

If RAMP loads up a french config (with french layer names for example), it would require preserving state over language switch, otherwise they'd get "heres all of canada and default layer settings"

[james-rae]

Feedback from me

Leaning away from Option 1, as it means we need language handlers on the page. Given our stock config setup will pretty much always have config per language (to support NrCan basemap labels and GeoSearch urls), means will always need some language + config handler code on the page. That said not a hard no against this option, could live with it.

Option two seems to give flexibility, and while it also needs a bit of page code, it's primarily setup code. Either "make instance, register configs, go" or enhance the instance constructor to allow multiple configs based on language. Once the setup is done, the lang switch will just work, and we accept it re-sets the page.

For the "multiple configs in the store" concern, I wonder if we could have these registrations live in a pre-store type area. They are registered, but only the active config is living in the store (not a vuex person so maybe i'm speaking nonsense). Doing a language change would look for a registered config to utilize in reinitializing the config store, if nothing found we leave current config store as is.

For multiple configs in a single language, I'd hope we could work around this in other ways. E.g. for CCCP instead of replacing the config the data selector fixture would do add and remove layers and adjust the legend via the API. If a full config replace is required we could adopt an overwrite of the pre-store config rule. I don't think we currently have any paradigm for ramp internally managing different configs for a language. For complex cases where we need full multiple configs per language, again I would hope a fixture or page code would handle the management.

For the "bookmark in English, then recipient wants French", I'd also hope the bookmark fixture would be able to do something like "start ramp, apply bookmark, notice language change via API event, re-apply bookmark" though I'm doing a lot of handwaving here.

So leaning towards Option 2 but can be ok with the other options.

[james-rae]

A wise retort from @spencerwahl

For the "multiple configs store" concern [...] only the active config is living in the store

I agree that this is the way to go

For multiple configs in a single language, I'd hope we could work around this in other ways. E.g. for CCCP

I was thinking about this a bit more again and CCCP would never have this issue because there are different pages per language. It would need to be a single page for both english and french together with multiple configs for each sort of thing, which is very unlikely to come up for us.

I'm also leaning towards Option 2 as well. I think option 1 (and to a lesser extent 3) only make sense if we expect language switching in the middle of using RAMP.

[AleksueiR]

I believe I commented on this issue previously on Slack, but that's history now :/

In my opinion, language switching should only change the UI language. There should be no side effects from language switching like reloading of layers or other things. I would also suggest a second axiom: two different configs make two different maps (as in if you switch language and a different config is loaded, it's a new R4MP instance completely unrelated to the old one; this is more akin to our samples page where a config is selected from a dropdown).

Accepting the above makes life easier for us:

• there is no need to indicate language of the map in the config
  • language of the map is derived from the host page language or is set by the host page through the API
• there is no need to have multiple configs for different languages (more on that below); we'll just keep using the same config
• there is no need to reload R4MP as the config doesn't change
• there is no need for bookmark and state preservation because we are not reloading anything
• a user can switch language to her heart's content

considerations

consider the usecase where a bookmark is created in one language and sent to someone who wants to view the content in a different language

there is the use case that a Francophone is emailed or shared a pre-canned URL in English, and wants to change language so they can view the data in their native language.

In this case, there is only a single config and switching language only change the UI language.

We can provide an option for the host page to specify layer names for different languages (maybe even bake this into the config), so that layer names are also switching to the new language.

Switching layers (say there is two versions of the same layer--one with English labels and one with French) when switching languages sounds like a convenience to the user, but is a headache for us. I don't believe we should do this as it's a very niche use case. There are two workarounds:

• make two configs with two different sets of layers and add a button to the host page to switch these configs; these flag can also go into the bookmark created by the host page, but that's not our responsibility;
• add two sets of layers (English and French ones) to the config as an exclusive visibility group and then users can switch between the layer sets inside a R4MP instance without having to reload the whole thing;

For multiple configs in a single language, I'd hope we could work around this in other ways. E.g. for CCCP

If we need to make CCCP again, I think the host page logic should be ultimately responsible for switching layers in a R4MP instance. It can do it by loading new fully-blown configs or just removing and adding layers to the map, but this doesn't affect how we should switch the map language.

[james-rae]

Switching layers (say there is two versions of the same layer--one with English labels and one with French) when switching languages sounds like a convenience to the user, but is a headache for us. I don't believe we should do this as it's a very niche use case

This is what our default lambert basemaps are, so it is the standard case, not niche.

Since most of your points are saying don't support this because rare, I'll pause here in case you want to re-evaluate (or maintain this is still your position). But effectively our basemaps mean every language change is a new instance if we follow the main proposal.

[AleksueiR]

Disregard my previous comments.

Option 2 👍

[yileifeng]

I've been working on the implementation of this and have come across a problem that's been discussed here.

It has been suggested that only the active config should be contained inside the config store. If this is the case, does anyone have any ideas on where these other registered configs should be stored? What are the advantages to accessing these registered configs outside the config store?

Otherwise, currently I have a property inside config store which is defined as follows:
registeredConfigs: { [key: string]: [RampConfig] } OR
registeredConfigs: { [key: string]: RampConfig } (if no multiple configs should be allowed for a specific language which is sounding to be the case)

This would be fairly easy to access inside config store functions like registerConfig(config: RampConfig) (for registering a new lang config) and setNewLangConfig(lang: string) for switching main active config to a registered config for the requested lang.

[AleksueiR]

I think keeping registered configs in the store is fine and I understand you are already implementing one config per language.

I don't think you need a separate setNewLangConfig function in the config store to switch active config. If configs depend on language, simply switching the language should be enough to trigger a bound getter that returns an active config:

const configState = {
   // { [key: string]: RampConfig } // key here is the language code 
   all: {
     en: enConfig,
     fr: frConfig   
   } 
};

const getters = {
      // get active config based on the current language
      active(state) {
           return state.all[globals.currentLanguage];
     }
}

[spencerwahl]

@AleksueiR what would the config state look like if theres no per-language configs? (one config handles everything)

[AleksueiR]

Hm, I can think of two ways, but it could be better just to register this config with all the possible languages:

const configState = {
   // { [key: string]: RampConfig } // key here is the language code 
   all: {
     en: unilingualConfig,
     fr: unilingualConfig
   } 
};

Then, no matter the language, it will return the same thing.

[sharvenp]

Cross-linking #948

[james-rae]

Closing this discussion, the cross-link will be the active continuation