Whilst the key/value approach is solid, the 'industry standard' .po (GNU gettext / https://en.wikipedia.org/wiki/Gettext) format supports more features, like complex plural and ordinal/cardinal number support that is a requirement in some languages.
In addition, some of the biggest issues with internationalization in my experience (~exclusively i18n projects for 10+ years) are generally missing/broken support in certain components (great reasons to contribute resources upstream for open source projects!), managing translations over time, cultural issues, right-to-left, differing program-level logic (eg. maximum SMS message length variations based upon character set requirements), differing seasons/days of operation/holidays. Calendars are of course a pain (though a solved one), as are timezones - for which a truly synchronized, global approach is frustratingly hard to deploy at the best of times.
The gettext PO file format does indeed provide many other features, I do not disagree, but there does seem to be an over reliance on it within the platforms I looked at.
The format does have some pretty major drawbacks too, like the msgid can become "fuzzy" which leads to a differing set of issues related to the unique keying between translations.
It also tends to lead to developers English (C locale if you like) being selected as the default language and it turns out developers like myself are sloppy and sometimes produce barely parsable messages.
Your remaining points are really valuable to someone inexperience in the field, like myself, so thanks for pointing those out.
It is interesting you call out cultural issues, did you have any specific examples?
> The format does have some pretty major drawbacks too, like the msgid can become "fuzzy" which leads to a differing set of issues related to the unique keying between translations.
I am not sure how much of an issue this is in practice. The main problem of the PO format AFAICT is that it is quite outdated. For instance, it has no support for genders and you cannot "mix" plural rules within a phrase.
> It is interesting you call out cultural issues, did you have any specific examples?
The wikipedia entry on l10n[1] has some examples.
The process of localization is not merely about translating some strings, but adapting them to a specific language and culture, which is the hardest part. For instance, your home page is one of the most important pages in your app and is geared to make as many people as possible sign up. Do you think a simple translation would have the same effect on British, French, Arabs, Japanese etc people?
Cultural issues include whether or not it is appropriate to bring up a particular point in the first place, visual design (eg. cultural norms for button or multi-point statement/list ordering, spacing, typeface size, etc.), special overtones implied by the use of certain words or combinations thereof, in some cases whether the use of text or icons is appropriate for a given translation, whether certain phrases or features should be 'off limits' (eg. due to cultural taboos, eg. impossible to configure a system in such a way that is disrespectful to one or more religious deities or real world monarchs), etc.
In addition, some of the biggest issues with internationalization in my experience (~exclusively i18n projects for 10+ years) are generally missing/broken support in certain components (great reasons to contribute resources upstream for open source projects!), managing translations over time, cultural issues, right-to-left, differing program-level logic (eg. maximum SMS message length variations based upon character set requirements), differing seasons/days of operation/holidays. Calendars are of course a pain (though a solved one), as are timezones - for which a truly synchronized, global approach is frustratingly hard to deploy at the best of times.