How possible is it to translate MODs (when 1.2.9 comes out)?

[wb99999999]

I am very excited about the localization options the next version will be including. I am a Chinese player who lives in Canada, and has been enjoying KSP and its amazing collection of mods for a long time. However, many people I know who are interested in the game, especially expansive multi-mod packs (like RO or KSPI) expressed concerns about not being able to understand the game and mods contents which are mostly in deeply flavored, sometimes very technically worded English. After reading the pre-release patch note for 1.2.9, I am starting to have an idea of translating some of the more influential and enriching mods, since the new version will support such capability and I am fairly literate in aerospace terminologies and KSP jargon.

I am not much of a computer person and know little about how licensing and permission works in the field of community created contents. Could anyone explain to me the likelihood of being able to do something like this (maybe with help from someone who are familiar with KSP mod development)?

[DStaal]

I suspect it'll depend heavily on how the mods are coded - whether they hard-code text into the plugin or if they can tie in to KSP's new localization system.

You'll probably have decent luck if you go to the mod authors and offer to help.  If you show them there's an audience and that there is someone willing to do the hard work of doing the translation, they might be receptive to making a translation possible - and a part of the mod.  They might want to wait until they see the release version of KSP come out before they start working on it though.

[dboi88]

I would be more than happy to include/work with anyone who wanted to provide translations in any of my projects.

[Diazo]

I'm already pretty sure how I'm going to do (at lest the initial implementation) of translations in my mods.

However, I'm not sure how it will handle right-to-left languages.

I'm hoping Unity is smart enough that if the computers system language is set to a right-to-left language, it will also display in that format but some testing is going to be required.

(I think Chinese is right-to-left?)

D.

[HebaruSan]

Mind if I ping you to translate my mod once 1.3 is out? I currently have 43 language-specific strings that would need attention, and up to now I had been planning to release with only English. I had a format worked out already, but I'm putting it on hold in hopes of making it more stock-like.

As for how easy translation will be, yes, it depends on the modder to make it localizable. SQUAD has said (in my bugtracker tickets) that they will publish documentation for their localization code once the current pre-release version is sufficiently stable. From browsing in MonoDevelop, it seems to mostly revolve around calling KSP.Localization.Localization.Format with strings along the lines of the examples at http://lingoona.com/cgi-bin/grammar.

25 minutes ago, Diazo said:

(I think Chinese is right-to-left?)

Top-to-bottom, I think.

[DMagic]

I've been planning on making a mod-localization thread at some point, with a list of mods and help on how to support translations. Sometime soon.

45 minutes ago, Diazo said:

(I think Chinese is right-to-left?)

Simplified Chinese is left-to-right (both when using characters and pinyin) as far as I know. I think traditional chinese is sometimes written top-to-bottom, but I imagine it isn't uncommon to be written left-to-right given how impractical vertical text could be in many situations.

 

14 minutes ago, HebaruSan said:

From browsing in MonoDevelop, it seems to mostly revolve around calling KSP.Localization.Localization.Format

Yes. You can easily use any of the stock text by finding the right text field in the localization files and using Localization.Format("#autoloc-1010101") to get the text in-game. Though I'm not sure on how well adding in text for mods would work (what would happen if mods use duplicate ids?).

[JPLRepo]

All of the implemented languages in 1.2.9 are left to right.
Switching it would require further changes.
More info on how to localize mods will be forthcoming.
It is quite easy, but a very laborious task (I can attest to that).
And of course the mods will require code changes.

[kerbiloid]

Most of the mods anyway use the same terms.

Maybe a forum section with a repository of term translations would be useful.

Edited March 21, 2017 by kerbiloid

[FancyMouse]

2 hours ago, DMagic said:

Simplified Chinese is left-to-right (both when using characters and pinyin) as far as I know. I think traditional chinese is sometimes written top-to-bottom, but I imagine it isn't uncommon to be written left-to-right given how impractical vertical text could be in many situations.

Modern days it's left-to-right regardless of trad/simp Chinese. Even Chinese novel books are almost purely left to right, while Japanese ones you can still see a lot of top bottom. But for the purpose of localization, any CJK language (Chinese/Japanese/Korean) can be safely assumed to be left to right. Unless you deliberately want to "be traditional" which I don't believe it's relevant in this community.

[wb99999999]

No, writing order shouldn't be a big problem. In video games/technology/internet fields the CJK language users mentioned has always been using left-to-right writing and it is almost the right way to write nowadays.

The problem is consistency. As a translator myself the least thing I want to happen is that someone who used a localized version of a mod while knowing a fair amount of English end up being unable to identify terms and functions used in the original mod text and spin-off mods: this can happen when the translators were taking too much liberty with local gaming jargon and/or trying too hard to make the text understandable for audiences who don't know a lot of engineering, aerospace technology and physics to start with...

[ShotgunNinja]

6 hours ago, DMagic said:

Though I'm not sure on how well adding in text for mods would work (what would happen if mods use duplicate ids?).

Exactly my throughs. It would be nice if human-readable IDs ids are allowed (like, #mymod-ui-whatever). If that turn out to not be the case, we could avoid duplicate IDs by choosing a random number from a very big space (like, 128bit). However then I'm not sure that I really want to deal with code containing these unintelligible numbers.

[Nils277]

3 hours ago, ShotgunNinja said:

Exactly my throughs. It would be nice if human-readable IDs ids are allowed (like, #mymod-ui-whatever). If that turn out to not be the case, we could avoid duplicate IDs by choosing a random number from a very big space (like, 128bit). However then I'm not sure that I really want to deal with code containing these unintelligible numbers.

human-readable IDs are possible. At least in a limited way, the strings have to begin with "#autoLOC_". I don't know yet if a naming with underscore in the subsequent id of the string is possible or if this suffers from the same bugs as the names of the stack nodes. But at least it seems to work with IDs like: #autoLOC_FUR.cockpit.description.

So there won't be a huge problem with duplicate ids when they are handled the same way as the IDs of the parts. I just wished the ids of the strings from the stock parts had more descriptive names. This would really make it much easier to find and use e.g. the already existing strings for crew reports etc.

Edit: The only thing i have not figured out yet is how the strings in the plugins can be replaced besides making all strings settable in the config files.

Edited March 21, 2017 by Nils277

[Diazo]

55 minutes ago, Nils277 said:

Edit: The only thing i have not figured out yet is how the strings in the plugins can be replaced besides making all strings settable in the config files.

I was assuming this was the way things had to go.

My basic thought was to provide an ENGLISH.lang, CHINESE.lang, etc. files in the typical configNode structure and then just load the correct string at run-time as per whatever has been set.

I can't actually look at the pre-release (my KSP computer is moving houses right now), but I'm waiting until I see how to interface with Squads's localisation code before I actually proceed.

D.

[Nils277]

56 minutes ago, Diazo said:

I was assuming this was the way things had to go.

My basic thought was to provide an ENGLISH.lang, CHINESE.lang, etc. files in the typical configNode structure and then just load the correct string at run-time as per whatever has been set.

I can't actually look at the pre-release (my KSP computer is moving houses right now), but I'm waiting until I see how to interface with Squads's localisation code before I actually proceed.

D.

Well, my curiosity won and i tried out how to access the localized strings in the plugin and it is really as simple as possible. You'd just have to make two things:

1. Import the localization module:

using KSP.Localization;

2. use the Localization class instead of the normal string. e.g.:

string description = Localization.instance.Tags["#autoLOC_FUR.cockpit.description"];

In code you can use the exact same names as for the config files.

Edited March 21, 2017 by Nils277

[Diazo]

But how is the data stored on the disk?

One thing I wanted to provide was a separate file per language so different people can do different languages without having to worry about consolidating them into one file.

D.

[HebaruSan]

On 3/21/2017 at 10:11 AM, Diazo said:

But how is the data stored on the disk?

One thing I wanted to provide was a separate file per language so different people can do different languages without having to worry about consolidating them into one file.

EDIT: Removed my previous post to avoid misleading folks. Best discussion of add-on localization is on this thread:

 

Edited March 22, 2017 by HebaruSan

[Dr. Jet]

My mod is already translated. Grab pre-alpha from last page and look how it was done.

[nascarlaser1]

I could use google translate to help (I know very few words in Spanish and that's about it .