Lessons From Linguistics: i18n Best Practices for Front-End Developers

Also, number and percent formats are important too. I've seen many 'professional' websites/software, that uses only a standart 100.0% format, where the decimal and the percent are not localised.

I've found that I need to support localization from the very start.

I never display a quoted string. I always use Apple's tokenization (or create my own, if doing server code).

Apple has terrific support for localization, which puts the onus on us, to honor it. I have some basic extensions that I use to support localization in my coding[0-2], but there's also just stuff I need to keep in mind, all the time.

There has been discussion of how to deal with things like word order in different languages. For example, in Germanic languages, the modifier usually precedes the subject, while in Romance languages, it tends to be the opposite.

Thankfully, Apple supports the "$" format for sprintf strings[3], so we can do stuff like this:

    import Foundation

    let localizationAssets = [
        (format: "The %1$@ %2$@", modifier: "white", subject: "horse"),
        (format: "Le %2$@ %1$@", modifier: "blanc", subject: "cheval")
    ]

    func localizedHorse(_ inLocalization: Int) -> String {
        String(
            format: localizationAssets[inLocalization].format,
            localizationAssets[inLocalization].modifier,
            localizationAssets[inLocalization].subject
        )
    }

    // English (Prints "The white horse")
    print(localizedHorse(0))
    // French (Prints "Le cheval blanc")
    print(localizedHorse(1))

[0] https://github.com/RiftValleySoftware/RVS_Generic_Swift_Tool...

[1] https://github.com/RiftValleySoftware/RVS_Generic_Swift_Tool...

[2] https://github.com/RiftValleySoftware/RVS_Generic_Swift_Tool...

[3] https://developer.apple.com/library/archive/documentation/Co...

I believe the library mentioned in the article (i18next) provides the necessary hooks to do this. See ‘saveMissing’ option [1].

Though you need a backend to save this and manage translations. The maintainer of that library, locize, business model is to provide such a service.

[1] https://www.i18next.com/how-to/extracting-translations

The code example should rather be an example of what not to do. This method of concatenating different parts of sentences would fall short for any language where the adjective and noun change the form depending on each other and the context (ex. cases). Most Slavic languages make heavy use of this concept. The solution is to just have the full sentence as a single string and let the translation team write it out in its entirety. Avoid interpolating nouns, adjectives, verbs etc. as much as possible.

It was just a silly example.

Of course, you are correct, but we don't always have the luxury of being able to hand an entire string to a localization team, and some programmatic interpretation often needs to be done.

The best way to deal with it, is to design code that allows entire sentences to be handed to translators (I do that, most of the time).

The other advantage of writing localized content, is that it can be easily modified by non-engineers, like marketing folks. Talking points and corporate glossaries are important. Even if we don't plan to localize, it doesn't hurt to use localization tokenized content.