Internal development notes, very slightly cleaned up and commented a week later.
TL;DR: A UI strings localization system has been implemented to enable both official and community translations, and work on bringing planets to the V3 engine has started.
- locale V3 api _L(new_game, "New Game") (_L "new_game" "New Game") the call first looks up "new_game" in the preferred lang dict, if not found, uses the second param a preprocessor extracts all _L calls and builds a tsv file it can also append to an existing file, to add new strings to translate translator script to extract C++/Scheme _L calls langs must be a mod! but they need to work at the earliest possible level (before game/rules are instanced) so still include manifest, but otherwise, the game looks ups Options::xxx and reads files from hardcoded in-mod paths spanish-mod/manifest.scm spanish-mod/main.scm (empty) spanish-mod/language/es/*.tsv this also works for any other mod, so they can add text in any language how to identify languages? manifest attrib: language-code: "es" language mods thus declare a language code how to enable single picker of single language mod vs other mods providing translations? mods providing translations for their own stuff just create the folder structure with the correct paths/codes they don't use language-code in manifest, this is only for translation mods Options screen for picking language mod shortcut from main menu load language mod before first UI display Shell::init is a good place for non-loaded game status (initial load) State::newGame/loadGame when new/load game is selected mod loader must also add each enabled mod dictionary to the locale dict, if the mod has any, for the current language code do it before calling main, so the strings are available even at the top level, before rules are ready - some initial work to find and prepare hardcoded strings (a few hundred for now, most others are from V2 and will disappear)
The top requested feature has made its first step in V3. The game now has a translation system for UI strings, based on the mod system. Mods can now declare themselves as a translation. Translation mods are not displayed in the normal mod list. Instead they are available in the Options screen, and listed as languages. Once a translation mod is selected it both provides a string list for translation (in one or more TSV files) in the usual keyword -> string format, and a language code. There’s no hardcoded concept of languages and language codes, so mods can provide completely new languages we haven’t thought about.
Non-translation mods can also provide translations for their own strings. The folder structure for providing translations is standardized, so as long as they provide their translations in the community accepted language codes (the usual ISO 639-1 codes (plus ISO 3166-1 when there is ambiguity) is recommended) the game will automatically pick them up.
This work enables both official translations and community provided ones.
- planet V3 re-make planet view based on IsoWorldView (make-planet-world rules body) create TileMapConfig stack according to Body meta data copy old planet color rules in c++, do no try to re-make in scheme - restore textured layers water, fog gas bg lava - check noise params for terrain, they dont seem to be right lava shows zero lava: missing hasLiquid ocean is too full - props: allow to set a sheet image/plist alias in the prop layer config - props: remove hardcoded rules, make them per-layer interaction with genProps interaction with IsoPropsLayer - setWalkable pass for planet, pre-props (just setWalkable on a, b or c terrain) - build layer for station maps - build and ground layer for cavern maps
Work has now started in adapting planet exploration to the V3 engine and gameplay goals. For now the basic map generators have been ported, and the map layers are expressed as a TileMapLayerConfig stack, like in the station. Some two year old bugs were fixed during this porting, like the stuttering gas giant background animation and the wrong 1-pixel offset in the water tiling texture.