Discussion: Localization, how to handle it?

[emilkris33]

We have already implemented a localization system to the code which look great. But this means that as we add text to the game we are going to get a lot of PRs like #146 with a lot of discussion most of us can't follow. Also this could be quite a lot of PR once we start adding strings and get people working on more languages. In general i think git is a lot better for handling code collaboration than localization collaboration that tells me that we should probably have translation happen somewhere else.

The way this would work is that we add only english strings while working in unity. Then when a new string gets to the TeamPorcupine/Master through PR the string list gets pulled into another tool where people(even those who don't want to touch unity or git) can translate. And then from that tool we export the translation files to unity, either at regular intervals or when ever significant changes exists. For this we could use one of the tools listed at https://github.com/integrations/feature/localization that have build in git integration or another tool. I have some experience using https://translate.google.com/toolkit/ which while not git integrated has the plus of being completely free.

What are everybody's thoughts on this?

[bjubes]

I agree that translating should occur outside of the git repo, especially because the subset of people who translate is different that those who code even if some people are doing both.

At this point in the project, many names and ui elements with text are very subject to change. while having code to handle localizations is nessicary, right now any language other than English may very well be a a waste of time when names of items are changed.

implement localization code now, translate and set up translation integration when the project's names and text are final

[SanteriHetekivi]

I also agree.

Made Finnish translation, just for a test of the translation system.
That got me thinking how it would be pain to update every time something changes in English version.

I would think that mostly everyone who are working on this project can at least understand English.

Also before UI resizing is implemented some of the translations are useless because of text length. -#164

[Tranberry]

What does Quill think, have he said anything on this topic somewhere?

[emilkris33]

@Tranberry I don't think @quill18 has addressed this. But he might see now that he has been tagged

[Fogsight]

It is a great idea to have more accessible area for people to contribute their translations, but languages should be represented right from the start for localization to work properly. They just could be updated properly later.

Because in Russian, for example, you'll need to mutate nouns depending on situation, it's less flexible than English. (i.e. This is "Steel Wall", but adding "Build" would change its form, and has to be a separate string, which can be avoided if you don't add "Build" in the first place.)

I'm not a linguist BTW, I'm sure there are many more pitfalls and in other languages as well.

[Aiwha]

I agree with Fogsight.
Although translating and updating the translations at every update is not ideal, it is essential that a good system is put in place as early as possible. I've seen a few game translation project where it was next to impossible to translate in some languages.

[brlodi]

I also agree with @Fogsight and @Aiwha that getting the framework solid is important early on. That said, the points mentioned above about putting in constant effort to keep many localizations up-to-date are very true.

To address Fogsight's specific concerns about varying language constructions, we should avoid programmatically constructing combined UI text. It's an unnecessary complication to adapt the code to handle every possible localization quirk. Just keeping it as simple string replacement ensures the people deciding the button text in a given language (assumedly people knowledgeable in it) have the final say on the output.

[Tranberry]

Would it be possible to default to english (en_US) where translations are missing?

[alexanderfast]

@Tranberry If a key is missing it defaults to english.

[Tranberry]

@Mizipzor must be after I tested .

[quill18]

Yeah, I feel that people jumped on localizing for ALL THE THINGS a bit too quickly -- they're just creating extra maintenance work for themselves.

Perhaps localization would be a great example of something that should be modularized (i.e. literally made into mods), which could then even be moved to a separate repo.

Still, I'm not opposed to having the language files in-place right now -- but I would minimize the effort put into keeping the language files (other than us_EN) up to date with all the furniture/UI changes. It's just going to be in too much flux right now to make it practical to worry about the languages.

Perhaps after we determine what features we will have as part of the Version 0.1 Milestone, we can then go ahead with the language updates to match. I would also NOT include any robot-generated language files in the 0.1 release.

[alexanderfast]

@quill18 I think that happened because the localization changes are very easy to do. People jumped on them because of that. If youre really eager to contribute something and maybe dont have the coding skill to make a complicated feature, thats the obvious step. And so what if it creates lots of maintenance, those same people now get to practice git even more.

Its a question Ive asked myself a lot recently, is this about creating a game or practice game development (for beginners)? The primary objective affects lots of decision, such as if it makes sense to implement multiplayer.

[Tranberry]

@Mizipzor you must have misunderstood what I meant. When I choose another language and there are strings not translated I would like it to default to English.

[alexanderfast]

@Tranberry This logic is in the GetLocalization.cs method. Maybe set a breakpoint there and find out whats going on? :) Or, tell me how to reproduce this bug and I'll fix it.

[brlodi]

Perhaps @Tranberry is concerned with the fact it still logs an error on falling back to en_US?

[alexanderfast]

Oh, now I get it. Unusually daft today. Sorry. Yea that can be fixed. I think its a good beginner task. Maybe we should wait for #375. @Tranberry You wanna give it a go? :)

[Tranberry]

No git fooled me again, I don't have the current pull/base/whatever I'll probably re-fork :/

[brlodi]

@Mizipzor I'm not sure what conclusion you came to, but I still think logging the missing localization is appropriate. "Build Steel Wall" is a nicer fallback than "build furn_steel_wall" but is still an undesired output that needs to be fixed in the localization file.

[alexanderfast]

@brlodi Theres actually two fallback modes in the code (currently three but one will be removed in a PR), it ether return the key or English equivalent. So its easy to swap between them. I dont know why that is a feature though, dont feel like something you would find in a settings menu. :P

[brlodi]

@Mizipzor oh I totally agree. I was just concerned that your epiphany might have been to remove logging from the FallbackMode.ReturnEnglish case

[alexanderfast]

@brlodi Nope, I rather like logging. :)

[brlodi]

Me too, as long as it's not once per frame for the same issue 😛

[vogonistic]

Do we need to do more work on localization, or is this issue past its close by date?

[alexanderfast]

Close it.

[mikejbrown]

Let's close it!