Refactor localized string definitions

[Clstroud]

History

Previously, we defined them as .strings files to have more detailed comments for translators and detailed keys to identify each string uniquely. This kept our code footprint relatively small, as it only required referencing the key and allowing the localization import/export engine to handle the rest.

Fast-forward to 2024, and Apple has given us new APIs and tools that make this process much better. However, there are a few wrinkles we need to design around. Part of the solution is shifting how we think about these definitions and, more importantly, what is required to support them on the translation side.

Future direction

Apple suggests we should define these strings in code as much as possible. Currently, we only reference them in code. We need a pattern for structuring the ontology of strings without making them burdensome to consume. Declaring them inline is historically not preferred because elaborate keys and comments take up considerable space in the editor.

Make better use of tables

Let's consider having a 1:1 mapping between screens and their accompanying translations. There are cases where this breaks down (utility classes that are shared between screens, for example), but in general, let's assume that SettingsViewController.swift can have an accompanying SettingsViewController.xcstrings file. This should make creating unique keys much more manageable with less verbosity/namespacing required.

Reflecting the tables in code

The specifics are worth discussing, but for starters, we could consider an additional file, SettingsViewController+Strings.swift, that pairs with the .xcstrings file. The goal would be for it to act as the source of truth for the .xcstrings file in the way Apple intends. The challenge is how we populate that file to create a pattern for consumption in the UI. In past projects, I have attempted to use extensions, type-specialization, and several other things to try and solve this problem satisfactorily. If we undertake a migration in Vocable, I would like to find an idiomatic solution that is minimal in its design and pleasant to consume.