Localization Kit

TEMPLATE NAME: Localization Kit
CORE VERSION: 1.0.191-prod-s
TEMPLATE VERSION: 1.1.2

TEMPLATE DESCRIPTION:
Based on the work started in Core World, the Localization Kit allows players to choose the language they prefer to play in, and the game adapts all texts to match that choice. Supports a flexible number of languages of your choosing and includes tools that solve many of the workflow challenges associated with the process of translating a Core game.

Core has a global player base. While English is a commonly known language, most players worldwide prefer to play in their local language and many don't know a foreign language at all. Localization is a high return, low cost investment to your game that increases player retention and engagement.

This package is open source and available at:

INCLUDED IN THIS PACKAGE:

  • README file - All setup and usage instructions.
  • Language Selection Popup - For players to choose their desired language.
  • Locale Text Scanner - Extract texts from an existing game to prepare for translation.
  • Spreadsheet template - For use in the translation process.
  • Loc Import Tool - For converting the texts back from the spreadsheet into Lua files.
  • Locale Manager - Provides the Localization API and saves the player's locale to storage.
  • Text Detector - Automatic replacement of texts at runtime, in UI elements.
  • Example Dynamic Text - Code reference for a common localization issue, where the text of a UI element changes at runtime.
  • Example Localized UI - Reference for a simple localization case, where the UI has static text.
  • Example World Text - Another simple localization case, but in 3D rather than 2D UI.

For questions and bugs please write in this forum thread. See the included README for instructions.

TEMPLATE VERSION NOTES:
1.1.1 - Initial release

3 Likes

Is there a way for this to handle multi-line strings on text fields now? I believe this was made before multi-line was supported - multi line strings will be generated as new rows in the localization table, so the first line of the string will appear with the proper TID but the subsequent lines will show up in the TID column instead of the enUS column.

Any quick fix for this? Like if we were to manually put them all on one line in the spreadsheet with something like \n at line breaks?

Bit of feedback - the ReadMe could do a better job of explaining how to manually add text to be localized.

A text's TID can be used instead of default text in UI elements and they
	will be replaced just the same. For example, a UIText can say
	"tid_button_play" instead of "Play". At runtime the Text Detector will
	swap it for the correct value. This is advantageous if you expect the
	English version of the text to be modified. This prevents human error from
	breaking the localization.

I need to test, but I believe the naming convention is "tid_", then the hierarchy name of the text object, then "_text" where text is the actual text of the UI object.

So if you want to add a new field to the localization sheet, I assume we follow that naming convention and all should be groovy, just wondering if we have to adhere to any max-character limits in the TID?

Re Multiline: This is true, it was created before multi-line existed. This is really something the tool needs to solve. I'll add it to my task list. In the meantime, you may be able to fix those manually. Try editing the log text in Notepad++ or something, before importing it to the spreadsheet. This would require reading through the entire output and fixing.

Re Manually adding text: The section of the Readme you are quoting is not related to adding new texts. That quote is about using TID directly in the game's UI, instead of the English copy. You want to use TIDs in cases where you expect the copy to change, so you only need to update the English copy directly in the sheets instead of fiddling through the game assets and also updating the sheets. If you don't use the TID and modify the English copy in the sheets, then localization breaks for that text, as the Text Detector has no way to find what it's looking for. The other case for using TIDs directly in-game is to handle ambiguity where the same English word can mean multiple things, but also in case of noun-gender and plural differences in languages.

I believe it's mentioned in the Readme somewhere, but you can name the TID absolutely anything you want. It just needs to start with "tid_". The auto-generator comes up with the names based on object and hierarchy, because it needs to base them on something. You can create your own naming conventions that make sense for your game and even rename all the TIDs to whatever you want-- There is no effect. There is also no max limit for the TID length, but in practice you'll want to keep them on the short-end to make it easier to read the sheets when you have bugs or a translator makes a boo-boo somewhere.