Refactor to load localization files by the core instead of separate Android and iOS ways #1842

New issue

Open

opened 2022-01-12 14:45:08 +00:00 by pastk · 3 comments

pastk commented

2022-01-12 14:45:08 +00:00

Owner

Benefits:

more straightforward implementation with less intermediate files and borrowed code (ditch twine)
single point to apply custom logic for e.g. defaulting types names (from types_strings.txt) to parent types and missing languages to default ones
easier to add localizations into qt app in the future (if we'll ever need it)

Challenges:

requires a big refactoring effort and the benefits may not justify it
we'll likely have to reinvent some wheels like plurals support

Anyway we should coordinate it with possible Weblate migration #659.

Original discussion (in Russian): organicmaps/organicmaps#1779

At the moment a localization source files (strings.txt, types_strings.txt, etc) are transformed to produce separate sets of platform-specific localization files for iOS and Android (we use a patched `twine` tool and some scripting to do it). The idea is to load localization source files by the cpp core and export localizations to the iOS/Android code from there. Benefits: - more straightforward implementation with less intermediate files and borrowed code (ditch twine) - single point to apply custom logic for e.g. defaulting types names (from types_strings.txt) to parent types and missing languages to default ones - easier to add localizations into qt app in the future (if we'll ever need it) Challenges: - requires a big refactoring effort and the benefits may not justify it - we'll likely have to reinvent some wheels like plurals support Anyway we should coordinate it with possible Weblate migration #659. Original discussion (in Russian): https://git.omaps.dev/organicmaps/organicmaps/pulls/1779#discussion_r778373330

biodranik commented

2022-01-12 16:11:49 +00:00

(Migrated from github.com)

The basic idea is to move only parts of translations into the core (like feature types). Everything else may not be worth it.

pastk commented

2022-01-12 19:59:40 +00:00

Author

Owner

The basic idea is to move only parts of translations into the core (like feature types). Everything else may not be worth it.

But it'll make the system even more complex and what will be the benefits?

> The basic idea is to move only parts of translations into the core (like feature types). Everything else may not be worth it. But it'll make the system even more complex and what will be the benefits?

biodranik commented

2022-01-13 07:50:47 +00:00

(Migrated from github.com)

The benefits are that there will be a single source of truth for types translations (and they can be easily merged and used with categories.txt).

This repo is archived. You cannot comment on issues.