Localization? What is it?

[GDJ]

Just like the title says, what is it in relation to KSP. I've seen plenty of references to it, but I have not found the answer.

Thanks for your time.

[Tex_NL]

Quote

Localization? What is it?

In my opinion it's an exercise in futility. A complete waste of time, money and effort.

In theory it is supposed to make the game 'more accessible' for non English speakers by translating it to other languages. But in practice it will just bloat the game with all kinds of files and textures the vast majority of people will never ever use.

[Vanamonde]

GDJ, it's one of those computer/sofware terms which no longer means what it literally says. In short, "localization" means creating a version of the game where all the text and info has been converted into another language, the "local" language, so more people can understand and play it. The next issue of KSP will have Chinese, Japanese, Russian, and Spanish versions. 

[GDJ]

2 hours ago, Tex_NL said:

In my opinion it's an exercise in futility. A complete waste of time, money and effort.

In theory it is supposed to make the game 'more accessible' for non English speakers by translating it to other languages. But in practice it will just bloat the game with all kinds of files and textures the vast majority of people will never ever use.

 

1 hour ago, Vanamonde said:

GDJ, it's one of those computer/sofware terms which no longer means what it literally says. In short, "localization" means creating a version of the game where all the text and info has been converted into another language, the "local" language, so more people can understand and play it. The next issue of KSP will have Chinese, Japanese, Russian, and Spanish versions. 

Okay, so the game will have extra text and textures related to text encoded in the game, and I'm assuming that when one starts a new game one selects the language of their choice. Sounds fair, but I can see how this might get bloated.

Five languages? It would be easier and less bloaty to have four different versions of KSP to correspond to the four languages being offered in the upcoming KSP 1.3. I would venture a guess and say that having five versions of the game would keep errors down to a minimum since each version would be specific to each languages, and having one version with 5 different versions of encoding would be ultimately problematic.

Or am I totally off-base here?

Edited March 13, 2017 by GDJ

[Dman979]

35 minutes ago, GDJ said:

Localization? What is it?

It's the process of making something local, but that's not important right now.

36 minutes ago, GDJ said:

having five versions of the game would keep errors down to a minimum since each version would be specific to each languages, and having one version with 5 different versions of encoding would be ultimately problematic.

Or am I totally off-base here?

I think that's a little off base. If you have one version of the game, with 5 languages, then you can develop a single game, and any bugs are the result of that single game. If you develop 5 separate games, with different languages, then you need to make sure that a bug in one game is for that game only, and it seems like it would complicate the process even more.

[Vanamonde]

Everybody will get the same KSP software, but will be able to choose the language in which the information in the game is presented. 

[katateochi]

8 hours ago, GDJ said:

Okay, so the game will have extra text and textures related to text encoded in the game, and I'm assuming that when one starts a new game one selects the language of their choice. Sounds fair, but I can see how this might get bloated.

Five languages? It would be easier and less bloaty to have four different versions of KSP to correspond to the four languages being offered in the upcoming KSP 1.3. I would venture a guess and say that having five versions of the game would keep errors down to a minimum since each version would be specific to each languages, and having one version with 5 different versions of encoding would be ultimately problematic.

Localisation for the pure text aspects should not add bloat if it's done properly. Having localisation for textures will require having multiple copies of the same texture just with the writing changed, but a) is that actually being done? b) if it is then (hopefully) only the textures for the selected language will be loaded into memory.

Having different versions for different langs would complicate things and make for much more work. Each change/fix would have to be copied over to each version and could result in even more bugs and the potential for discrepancies between the versions. 

For the text localisation, it should just be a process of abstracting interface text (labels, error messages, any text the user sees) out of the main code and putting it all into a lang file. So for example (in pseudo code) if you had a bit of code like this;

Spoiler

if something_went_as_expected
    show_msg("The thing worked as expected")
else
    show_err("omg stuff exploded")
end

It would get changed to something like this

set_lang("eng")
if something_went_as_expected
    show_msg( i18n.t("worked_as_expected") )
else
    show_err( i18n.t("stuff_exploded_error") )
end

and then you have a .yml file for the English something like eng.yml

eng:
   worked_as_expected: "The thing worked as expected"
   stuff_exploded_error: "omg stuff exploded"

and you'd end up with all the interface text in a single .yml file.
(i18n is often used as shorthand for "internationalization", 18 stands for the number of letters between the first i and the last n in the word internationalization)
in this example i18n.t is a call to "translate" the given text into the currently selected language, which is just a lookup in the set lang file of the given text and it returns whatever matches)
 A lang file can have much more structure than in the above example, so you could have stuff_exploded_error.formal and stuff_exploded_error.casual if some slight variation was needed.

Then to support another language all you have to do is translate the contents of the yml file, ie for French (although I've no idea if that's a correct translation, I just google translated the above text)

fr:
   worked_as_expected: "La chose a fonctionné comme prévu"
   stuff_exploded_error: "Omg a explosé"

and then in the initialisation of the code you just call set_lang("fr") instead.  So the only addition for another language is adding a new text/yml file with the translations and the main code remains unaltered. It also makes grammar/spell checking the user facing text much easier as it's all in one place and can be done without wading through all the code (so can be handed off to non-coders).

 

[kerbiloid]

And those who don't want to bother with searching for quoted strings like "Press any key" through the whole program sources, never put something "quoted" in the code.

They gather text constants in one file

  std::string const TEXT_PRESS_ANY_KEY = "press any key";

And then use TEXT_PRESS_ANY_KEY in the functions.
They hate any highlighted quotes in the middle of the code.

 

Or even organize them in a class:

class CTextConst
{
static std::string const PRESS_ANY_KEY = "press any key";  // in fact, this static definition should be out of h-file here
}
and then call them like CTextConst::PRESS_ANY_KEY

Then they have to translate only one file, instead of searching.

 

Sometimes, when there are many text strings, they don't place them inside the program code at all.
They make something like:

class CTextConst
{
enum class EText
{
..
PRESS_ANY_KEY = 1254
...
}

public:
std::map <EText, std::string> mapText;

}
Then read the string from the text into the map and mention them as something like this:

CTextConst:::mapText[CTextConst:::EText::PRESS_ANY_KEY]
or define a macro for the "CTextConst:::mapText[CTextConst:::EText::" part

But usually the third way is not required as most of developer soft has its own mechanism for text resource files.

Edited March 13, 2017 by kerbiloid

[JPLRepo]

There won't be the bloat you think. We've done it in such a way as to reduce this as much as possible. Really it's the same files and text as is packaged already for English (almost). Selecting languages will mean the language files for that language will be downloaded and inserted (replacing previous) - if using steam. @kerbiloid is pretty close to the money. KSP Store will be a bit different. More info will be provided on how it works etc as we get closer.