Localization/translation of datafiles (catalogues)

[amis92]

There were some requests for hosting localized datafiles (BSData/bsdata#174, BSData/bsdata#199).
BattleScribe has no support for datafile localization.

There might be such support in future, but it's currently not even on a roadmap.

[OftKilted]

There has been an additional request for localization here: #24

[afcj]

@amis92

I'm open to further discussion, though. Maybe you have some interesting solutions?

Maybe the XSD should admit translation subtags in any tag that have a translatable attribute, so the application read the default attribute if there are not subtags but can read the translations from the subtags is they exists and you have select it.

For example:

<profile id="6edb-7600-2699-d7c3" name="Command Stick" hidden="false" profileTypeId="2421-adf7-5cec-846a" profileTypeName="Weapon">
  <characteristics>
    <characteristic name="Range" characteristicTypeId="df8a-ee5b-d620-4246" value="Ra"/>

should be:

<profile id="6edb-7600-2699-d7c3" name="Command Stick" hidden="false" profileTypeId="2421-adf7-5cec-846a" profileTypeName="Weapon">
  <translations>
    <translation name="Bastón de Mando" profileTypeName="Arma" language="es"/> 
  </translations>
  <characteristics>
    <characteristic name="Range" characteristicTypeId="df8a-ee5b-d620-4246" value="Ra">
      <translations>
        <translation name="Alcance" value="AL" language="es"/>
     </translations>
   </characteristic>

So in just one file you can have all the translations with shared rules, and if you don't want translations you just don't use them and let the translations tag empty.

There is a smarter way to do it throught XSLT (an example in https://stackoverflow.com/a/32524605/4682306) but maybe it will be more difficult for BattleScribe to interpret it (you should know better than me).

[afraeve]

I've been using standard modifiers for the rules translations in the Epic Armageddon repo (yeah, I know, the html tags don't work anymore) but no-one ever leaves any feedback, so I don't know how worthwhile it is.

[evertonpendragon]

Localization #36
The translation itself can be automated because it uses Google Translator API, so it can tranlate any game system to any language. I tested only with wh40k, but it can be extended to any system.

The program downloads the latest wh40k release and translates it, I create the bsr file and upload it to the release page.

Today there is no other way to get a translated repository wthout creating a new repository because BS does not support multi language catalogues.

To start, I propose creating a new repo in portuguese language. It can serve as a pilot projetc, and if it is successful, other languages can be implemented.

I can share the source code if you want to take a look.

[amis92]

The issues that I see are as follows (ordered from most to least important):

1. Do we create new repository for every new localization of every other repository? My view is we should keep these as a part of the same repo.
2. Since we're certainly not getting BattleScribe localization support (built-in) any way soon, we should decide on the localization implementation:
   1. Format of localization files (do we use any existing, or try to build one ourselves)
   2. Tools that will automate building localized files (@evertonpendragon wrote some script, there's wham tooling already doing some stuff like .bsr packaging)
   3. Running these tools in automated manner (AppVeyor, GitHub Actions)
   4. Adding support for localization in AppSpot site
   5. How to manage the actual localization files - maintainers, translators etc.

[amis92]

For the record, there was a discussion on gitter (permalink to first message: https://gitter.im/BSData/wh40k?at=5c3257d13cf6c35a849f036f)

Screencap (hidden for brevity):

[DarkSkyT9A]

Additional request for built-in localization from me here. Shouldn't really be a difficult feature, @afcj already showed a potential solution.

[amis92]

@afcj's solution requires BattleScribe to know about this. We don't have the ability to introduce that feature.

The one-off solution is easy, of course. Keeping all of this under tabs, maintainable - it's a very different beast.

[DarkSkyT9A]

@amis92 yeah I am aware of that. But can we not gather this input and present it to the one person able to change this?

With a lot of people around the world and many not able or not willing to work with English names, this sounds like a no-brainer to be top priority for implementation to me.