At the moment, localization efforts involve modifying a local JSON file, establishing the language's existence across dictionaries scattered in multiple files, and adding UI localizations to data structures that are otherwise data-specific localizations (specifically, the category names for weapons). Many language fallbacks, such as NOA localizations for Spanish and French defaulting to NOE, are represented in hard coding in the data structure.
A better system would function as the following:
All relevant UI localizations are contained within the JSON files.
All localization JSON files declare a "fallback" language to use for weapon, gear, and UI strings that are missing for that particular localization.
-- This can be English by default (English will always be available), but changed to appropriate languages that would make sense for the localization (zh_HK -> ja_JP, es_MX -> es_ES, etc)
At build time (during the gulp task), automatically detect all localization files located in the /locale directory. Then:
-- Generate any dictionaries necessary for language implementation in-code, using the locale files.
-- Assign the default "fallback" languages for any localizations that are missing them.
-- Use the "fallback" language in any place that is missing a localization string.
Anywhere the application needs to retrieve a localization manually (currently, for game data), allow for the fallback language to be used.
Such an implementation would mean that localizers only have to worry about adding and modifying the locale file, and would immediately be able to test and see their work by building the project, with no other changes to code necessary. It would also be significantly easier to maintain and add new localizations.
At the moment, localization efforts involve modifying a local JSON file, establishing the language's existence across dictionaries scattered in multiple files, and adding UI localizations to data structures that are otherwise data-specific localizations (specifically, the category names for weapons). Many language fallbacks, such as NOA localizations for Spanish and French defaulting to NOE, are represented in hard coding in the data structure.
A better system would function as the following:
Such an implementation would mean that localizers only have to worry about adding and modifying the locale file, and would immediately be able to test and see their work by building the project, with no other changes to code necessary. It would also be significantly easier to maintain and add new localizations.