Augment Localization Support

[AnakinRaW]

User Stories:

• I want to load a .Dat file, so I have access to it's higher level data (Key - Value)
• I want to export my in-memory localization to a .dat file so it can be used by the game.
• I want to open an translationManifest.xml file so I have access to it's higher level data (Key - Value - Language)
• I want to create an translationManifest.xml file from one or many .dat files so i have all my localization in one VCS compatible file.
• I want to export an translationManifest.xml file to multiple .dat files so the game can use them.
• I want to validate a loaded .dat or .xml file with a given error report, so i know where errors are.

Additional Requirements

• A .dat and a .xml file SHOULD be exchangeable. This means at any given point the API should allow me to either use one or many .dats or one .xml file.
• The translationManifest.xml MUST not use hardcoded languages in its implementation. This issue was already addressed in the original implementation.
  Petroglyph provided all languages the game engine supports. The implementation will expose a ILanguageDefinition that will be used throughout the implementation and can be expanded upon, but all official *LanguageDefinitions will be provided as sealed classes.

Architectural Details

Localization Service

The localization service is an API that contains a meta model for multiple localizations (e.g.Interface name: IGameLocalization. It MUST hold multiple localizations identified by the english culture name (however we MUST not hardcode the possible language names ([gruenwaldlu]: The possible languages will however be restricted to elements implementing the ILanguageDefinition)). Each language has a simple key-value data store for the actual translations. Data validity checks, TODO handling, etc. is exposed through this service.

Dat File Service

This is an IO API responsible for loading/storing .dat files. The data model which gets transformed from/to a .dat file comes from the Localization Service.

TranslationManifest File Service

This is an IO API responsible for loading/storing translation manifest .xml files. The data model which gets transformed from/to this .xml file comes from the Localization Service. This Service also acts as an concrete implementation of the TranslationManifest Specification.

TranslationManifest Specification

This is an interface only API which defines all data types necessary for a TranslationManifest.

Localization CLI

This is an CLI tool which allows to perform the above described user stories.

[gruenwaldlk]

I finally got around to properly looking at this...

• Localization Service
  Currently I have the idea of making that a service that doesn't care about its source, so the initialisation has to provide the source type; e.g. DI-based.
  In addition it would provide either mutliple stores of key.value-pairs that are referenced by language, or it would a single store that holds the keys, then all the values by language. The latter would make it easier for duplicate checking, etc. The former would separate the translations.
• Service
  We basically need a load service that handles a format based on a specifier (DI probably) so we have a single interface that can handle any format that is supported.
• TranslationManifest Specification
  There is an xsd around, so that shouldn't be a problem, but the question is, do we need this within the whole toolset?
  Ideally we'd initialise the GameLocalizationService like this: IGameLocalizationService svc = Services.get<IGameLocalizationService>().create(filesystem, loggerFactory, fileHolder, FileType.Dat) so within the repository I don't think we need an explicit specification. But we should make at least the xsd acessible in an easy way, probably similar to how we handled the EaW mod info.

So based on the amount of work described here, I'd probably turn this into a milestone, and pull out the stories as single issues, so it's less of a monolith.

[gruenwaldlk]

The following languages are officially supported by the game engine as confirmed by Petroglyph:

• THAI
• POLISH
• RUSSIAN
• CHINESE
• KOREAN
• JAPANESE
• ITALIAN
• SPANISH
• FRENCH
• GERMAN
• ENGLISH

[gruenwaldlk]

To expand upon this:
The official languages are hardcoded as an enum in the PG.Core project, can be converted to and from their string identifier and their associated CultureInfo, which provides us with means to validate against that official list.

Within the context of the PG.StarWarsGame.Localisation project, all language related operations work with elements implementing the ILanguageDefinition interface which exposes the string identifier and CultureInfo. The project provides default implementations of the interface for each official language, but those can be expanded upon in projects using the package.

So we have the benefits of the hardcoded languages (validation) and still keep the PG.StarWarsGame.Localisation package expandable.

[AnakinRaW]

Also separating translations is devided objects means we need keep them in sync. So I think i tend to the single store variant.

We basically need a load service that handles a format based on a specifier (DI probably) so we have a single interface that can handle any format that is supported.

I guess that's just another abstraction layer, but sounds reasonable.