technicat/fedicat-localization: localization for fedicat - Codeberg.org

This is the localization data for Fedicat (issues should be reported in the fedicat repo). What I actually edit is the top-level Localization.xcstrings, which is the main string catalog. I copy it here from the Xcode project periodically using a Gauche Scheme script.

The set of localization keys, like the rest of Fedicat, is highly volatile. In fact, I'm trying to reduce the number of localization keys through reuse and simplifying the interface. To reduce typos, keys correspond to the raw values of enums (Localization/Title.swift) in the Fedicat repo (so we're moving to camelcase and away from dot-separated key names). This doesn't work for localization keys with parameters, but that's no worse than the new SwiftUI localization enum generation, plus it allows mixing upper and lowercase versions of the same key. The keys are named so that they will still be understandably read or voiced if a translation is unavailable.

I'm gradually adding languages, but the only one I'm confident in is English, and the whole set is going through constant revision. Goals include correctness, consistency, sensitivity, and brevity, in no particular order.

yue is Simplified Cantonese, so we have something for both yue-Hans and yue-Hant, but yue-Hant should be added to override.

As a starting point, I try to be consistent with localization in Apple's apps, some of which are listed in their localization glossary, (although some are referred to by codename, so it takes some guessing which it app it is. Marmoset?). The advantage of matching the glossary is if it's in there, besides consistency with Apple usage, it's available for all languages that Apple supports on-device, though not necessarily every specific regional variation, e.g. not all the variations of Spanish, but es will cover all of that, and es-419 (Latin America Spanish) will cover Mexico, Puerto Rico, etc. Unfortunately, once you add a language, you have to add all of it, just adding one entry for fr-CA means you have to fill in all keys for fr-CA, they won't default to fr.

Then wiktionary and wikipedia (good for names of programming languages and artists), and longer phrases (hard to avoid with accessibility labels) from app (google, libre, deepl...) or [human] translate(https://fedicat.com/credits/#localization).

Additionally, it would be good to be consistent with what is used in other fediverse apps that are substantially localized, e.g. Mastodon, Ice Cubes, Phanpy...(still a lot of variations, e.g. boost is all over the place) and other relevant apps, e.g. IMDB for movie-related (neodb) terms.

Ideally, each translation would specify one or more references, whether it is from the Apple glossary or another app. Unfortunately, the string catalog only provides one comment field per localization key and not per translation, so it all has to be crammed in there.

Other resources include the Phanpy readme, Unbabel language guidelines, Cantonese.org, Vietnamese Tools, various language stackexchange

I run the loccheck.scm script from my Scheme utilities to check the coverage for each language. It scans localization.xcstrings so it can be run in this repo or generally in any Xcode project that using localization.xcstrings (some older ones haven't upgraded). [jsonlint] is also really handy.