Localization/translation of datafiles (catalogues) about catalogue-development HOT 13 OPEN

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.

from catalogue-development.

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

from catalogue-development.

@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).

from catalogue-development.

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.

from catalogue-development.

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.

from catalogue-development.

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

from catalogue-development.

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

from catalogue-development.

@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.

from catalogue-development.

@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.

from catalogue-development.

For you and for me, sure (I'm from Poland, we don't even get translations for most wargames).
If you're up to writing up something like that, feel free. I don't have time/don't want to invest in that.

Repo for BattleScribe: https://github.com/BattleScribe/Release

from catalogue-development.

If anyone chooses to pursue this, I recommend you take a look at DeepL Translator: https://www.deepl.com/translator
It's a lot more user-friendly than Google Translate, plus the output seems much more natural, too. I don't know if it can work in any automated sense, but given the amount of finessing it takes to swap out the right nouns and things, there's no way you could rely on a fully automated set-up.

from catalogue-development.

Note to self: https://weblate.org/en/

from catalogue-development.

@isorna @Kassbinette @afcj @petreopatroklos @Xandarck

You've all asked previously for hosting translations. I do not have the news you wanted, nevertheless it may turn out useful. BattleScribe still doesn't support translations. And we still don't want to host separate translated repositories.

However, we now have a nice guide on how to host your repositories more conveniently so that they're easily accessible to your audience via GitHub. Please give the following page from our wiki a read: https://github.com/BSData/catalogue-development/wiki/Help:-Hosting-repositories

from catalogue-development.