> On Apr 26, 2016, at 16:16 , Dave Abrahams via swift-evolution > <[email protected]> wrote: > > Also, frankly I think printf syntax is arcane and readable only to a > small fraction of developers. Take a complete read through the man page > sometime if you really want your mind blown! > > If you're going to take a string interpolation approach, we can instead > know *exactly* what formatting options apply to “foo,” express them > readably, and check them at compile time. > > The problem is that localization may really be incompatible with > Swift-style compile-time-checked string interpolation with embedded > formatting, because of: > > 1. The need to look up localized strings in tables for a given language, > making them basically dynamic as far as the compiler is concerned. > > 2. The need for localizers (i.e. not the application programmer) to > tune both the string content and how the arguments are formatted.
Very true. Separating localizable strings from source code is critical to making the localization process manageable, and the syntax used in localizable strings must be easy to understand for translators, who are hardly ever engineers, or supported by the tools that translators use. Localization of messages also has some requirements that haven’t been discussed here yet: – Inserting a number into a sentence often requires adjusting other parts of the sentence (nouns, verbs, articles) to the number. And while English has only singular and plural, other languages distinguish more cases – up to six for Arabic. – Inserting a name or noun into a sentence often requires adjusting other parts of the sentence to the gender of the person or noun. While in English gender usually is only reflected in pronouns, its impact is pervasive in some other languages. – Formats for numbers and dates should be specified at a high enough level that they can be automatically translated by internationalization libraries. For example, don’t specify the order of year, month, day and the characters to be used around them; specify just whether you want to have a long or a short form and which components, and let an internationalization library handle the rest. One well supported and commonly used library handling this is ICU with its MessageFormat class: http://userguide.icu-project.org/formatparse/messages http://icu-project.org/apiref/icu4c/classMessageFormat.html#details If there is dedicated support for localizable messages in Swift, it should be at least as good as MessageFormat – and translators should have at least as strong a say in what’s good as software engineers. Norbert _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
