Draft: Resolve "Implement Internationalization Feature"
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
-
@SiLAOrganisation: "all user experience relevant things"
- @NMertsch: what does this mean?
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 toSiLAService.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?
- 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?
- @SiLAOrganisation: Raise an error (Defined Execution Error)
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?
- @SiLAOrganisation, @stekoch: don't merge until verification
Edited by Niklas Mertsch