Skip to content

Draft: Resolve "Implement Internationalization Feature"

Niklas Mertsch requested to merge 36-implement-internationalization-feature into master

Closes #36

Hard requirements

  • gRPC communication must be untouched
  • language must be a client-specific setting
    • if the language is a server-wide setting, there cannot be multiple clients using the server in different languages

Scope

Static (feature definition language)

  • unit conversions
    • @SiLAOrganisation: yes
    • @NMertsch: has static and dynamic part (static: FDL tells client about the unit of received values, dynamic: server has to determine in which units the values have to be translated)
  • strings
    • identifier
    • display names
    • descriptions
  • @SiLAOrganisation: "all user experience relevant things"

Dynamic (at runtime)

  • unit conversions
  • error messages
  • strings in (intermediate) responses and property values

General design considerations

Strictness

  • @SiLAOrganisation: A language must either be fully supported, or not at all.
  • @NMertsch: A language should be fully supported. Implementing 95% of a server in another language (on the server- and client-side) probably is much less effort than implementing the last 5% (e.g. translating all forwarded messages from connected subsystems, custom unit conversions, ...). Server vendors have an intrinsic motivation to do their best effort if they provide support in multiple languages. If we are too strict, this will prevent adoption.

Need of library support

  • @NMertsch: Must not be required. Implementing generalized internationalization capabilities in the SiLA reference implementations is a complex and large task. At the current state and pace of development and considering the current development resources, I doubt this will happen in the foreseeable future. So I propose that this feature should be feasible to implement by library users on the server and client side.

Ease of individual implementation on server and client side

  • @NMertsch: Implementation complexity should find a balance on the server and client side. If implementing internationalization on a server is hard, no server will provide it. If implementing internationalization on the client is hard, no client will make use of it.

Conceptual Implementation

How do we provide static internationalization?

  • @NMertsch: Command GetTranslatedFeatureDefinition(FeatureIdentifier, LanguageIdentifier) -> TranslatedFeatureDefinition, works similar to SiLAService.GetFeatureDefinition provides fully translated feature definitions
    • Easy on the server side, inconvenient on the client-side (compare/match original and translated XMLs)
    • SiLA does not specify fully qualified identifiers for some elements (relevant here: structure elements, unit constraints). So we cannot say "item X is internationalized to [...]".

How do we provide the possible internationalization options?

@NMertsch:

  • If the server must fully support a language for all features: Property SupportedLanguages, type: list of language identifiers
  • If the server can provide different options per feature: Property SupportedLanguages, type: mapping of feature identifiers to lists of language identifiers (implemented as structure)

How do we provide dynamic internationalization?

@NMertsch: Metadata Language, type: language identifier

  • What shall the server do when receiving a language that is not implemented?

Technical details

How to identify a language?

Is "language" the right term?

  • Localization? Locale?

Maturity level on merge

Shall we keep this MR open until the feature is officially verified, or merge it as draft?

Edited by Niklas Mertsch

Merge request reports