🐞 Inconsistent and bug-prone localization approach

[Jeehut]

Problem: The localization story of this project seems to be unclear. I found this String extension which is supposed to be used to get autocompletion by adding all keys into the LocalizedStringKey extension in the same file. But none were added yet except the first sample "Hello World" entry.

Still, in some places I see calls into localized(), even in places where you could simply pass a plain String literal because the LocalizedStringKey type is already StringLiteralConvertible, thus no localized() call is needed to localize it.

At the same time, in some places there's no localized() call and in some places there's not even a translation key inside the Localizable.strings file. This problem will get larger and larger over time with more and more keys added. Later, with more languages, it will also be hard to keep up with translations.

Additionally, the current localized() approach does not support Stringsdict files.

Solution: I suggest we use the popular tool SwiftGen instead of the .localized() approach or plain LocalizedStringKey from SwiftUI, which has the following advantages:

1. It will be obvious just by looking at the code which strings are not yet translated (any String literals) and which are (all localized Strings will start with L10n. enum prefix).
2. It prevents shipping any code that references String keys that no longer exist in the Strings file, because the compiler will simply fail when the key was renamed or removed.

Additionally, I suggest we use the tool BartyCrouch (full disclosure: it's written by me) to further prevent letting translation issues creep into the project over time by using it's linting functionalities, such as:

1. It's easy to forget translating some keys in some languages
2. It's easy to forget even adding a key into one of the language files
3. It's easy to miss removing or changing the name of a key that is being changes/removed
4. Sometimes it happens that the same key is added twice, leading to ambiguous lookups in runtime

BartyCrouch also greatly simplifies adding new keys to many language files in one go (read this blog post where I explain it in more detail).

The installation of SwiftGen and BartyCrouch should be also documented in the CONTRIBUTING.md file.

I would be up to set this all up myself as I have some expertise here, but of course only if this is a wanted path.

[Angelk90]

@Jeehut : Does it also work with xib files?

[Jeehut]

@Angelk90 Yes, it works with XIB files, too. BartyCrouch actually extracts and incrementally updates the localized strings from them. That's why I had initially created the tool in the first place, because adding new keys was really tedious, especially with many languages supported.

[nanashili]

Closing issue for now till we add support back for localisation.

[Jeehut]

@nanashili @lukepistrol You seem to have decided that localization will happen at a later stage, which I can totally understand. Do you have any details on when localization would be added? I have some expertise here (I am currently even writing an app to simplify localization) and I can not find a thread where this decision was made with additional details. Do you plan to add it before 1.0 release or after, for example?