You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When authoring snapshots for bilingual regions (e.g. certain cities in Switzerland, Canada, South Africa etc.) it would be helpful to add support for multiple locale versions for any localisable content like titles and descriptions, legend entries etc. Even map content could have localised resources for different languages/regions.
Technical background
Matching localisations to application settings/user preferences should be based on the IETF propsed language tags, combining language codes defined by ISO 639-1 alpha-2 and region codes defined by ISO 3166-1 alpha-2 into a string separated by a hyphen. E.g. it-CH for Italian speaking regions Switzerland or fr-CA for french speaking regions in Canada or de for generic German version.
One for each supported locale by adding a view.spec.locale key.
This will work with existing setups, since the first view can be considered the "fallback" and hence work as is. Conversely old snapshots will not break since no changes are needed, new versions can implement a check if locale keys are present and if yes matched to application settings.
This only works inside snapshot.views. Where implementations are using standard Data Package functionality (namely sources and resources) other options need to be used, making this approach heterogeneous at best and confusing for new users.
Option 2: Inline localisation for relevant keys with an optional i18n dictionary
In this option a single snapshot.view, snapshot.sources etc. object would be kept, however each key that needs localisation can now have an additional entry inside an i18n object specifying localised versions replacing default strings where needed. If no localised string is provided the original (fallback) one is used.
Implementations without i18n support can simply ignore the additional i18n entries. Conversely when authoring a snapshot adding localisation is also optional since only the fallback entries would be used if no localised strings are available.
To replace default strings with localised ones the relevant structures and entries are reproduced inside an i18n dictionary.
The fallback language after matching locale keys can either be by convention (view with index 0) or an extra key, e.g. view.defaultLocale.
n0rdlicht
changed the title
Proposal: Support for localisation/internationalisation (i18n)
Support for localisation/internationalisation (i18n)
Mar 26, 2021
When authoring snapshots for bilingual regions (e.g. certain cities in Switzerland, Canada, South Africa etc.) it would be helpful to add support for multiple locale versions for any localisable content like titles and descriptions, legend entries etc. Even map content could have localised resources for different languages/regions.
Technical background
Matching localisations to application settings/user preferences should be based on the IETF propsed language tags, combining language codes defined by ISO 639-1 alpha-2 and region codes defined by ISO 3166-1 alpha-2 into a string separated by a hyphen. E.g.
it-CH
for Italian speaking regions Switzerland orfr-CA
for french speaking regions in Canada orde
for generic German version.The relevant parts of a
snapshot.view
here are:datapackage.view.spec.title
datapackage.view.spec.description
datapackage.view.spec.attribution
datapackage.view.spec.legend.label
datapackage.sources
datapackage.title
datapackage.description
datapackage.keywords
datapackage.resource
sOption 1: Create fully distinct
snapshot.view
objectsOne for each supported locale by adding a
view.spec.locale
key.This will work with existing setups, since the first view can be considered the "fallback" and hence work as is. Conversely old snapshots will not break since no changes are needed, new versions can implement a check if locale keys are present and if yes matched to application settings.
This only works inside
snapshot.view
s. Where implementations are using standard Data Package functionality (namelysources
andresources
) other options need to be used, making this approach heterogeneous at best and confusing for new users.Example
Option 2: Inline localisation for relevant keys with an optional
i18n
dictionaryIn this option a single
snapshot.view
,snapshot.sources
etc. object would be kept, however each key that needs localisation can now have an additional entry inside ani18n
object specifying localised versions replacing default strings where needed. If no localised string is provided the original (fallback) one is used.Implementations without
i18n
support can simply ignore the additionali18n
entries. Conversely when authoring a snapshot adding localisation is also optional since only the fallback entries would be used if no localised strings are available.To replace default strings with localised ones the relevant structures and entries are reproduced inside an
i18n
dictionary.The fallback language after matching locale keys can either be by convention (view with index 0) or an extra key, e.g.
view.defaultLocale
.Example
The text was updated successfully, but these errors were encountered: