So my college is writing a desktop app (usually my domain), and he doesn't want to do internationalisation because of time constraints. HARD CODED STRINGS EVERYWHERE!

I started asking to get draft templates in German language. So at least we'll know what the site will look like what when text is very long and customers are called "Sebastian Wiedenmann" instead of "John Doe".

Remember English is a very concise language and you always get bad CSS surprises when applying translations.

Development Process:
PM writes out functionality required and works with designer for drawing up designs.
Hands off to Dev.
Dev reads through all docs and sends the PM all the strings, he's just written down in the documentation, that he needs to request for internationalisation.

I use the ICU format often for translation because it's simple enough and supported on many platforms. It's something of a standard so I can use the same translation string format and similar library functions everywhere.

ICU is like a really simple templating language, somewhere between printf and something like smarty or twig simplified and specifically intended for internationalisation.

I updated a library providing ICU compatible parsing and formatting for one of the platforms I'm using and find tests break. I assume that only thing to change is the API. ICU very rarely changes and if it did it would be unexpected for it to break the syntax in a major way without big news of a new syntax.

The main contributor of the library has changed since some time last year. Someone else picked up the project from previous contributors.

Though the library is heavily advertised as using ICU it has now switched to using a custom extended format that's not fully compatible and that is being driven by use case demand rather than standardisation.

Seems like a nice chap but has also decided for a major paradigm shift for the library.

The ICU format only parses ICU templates for string substitution and formatting. The new format tries to parse anything that looks XML like as well but with much more strict rules only supporting a tiny subset of XML and failing to preserve what would otherwise be string literals.

Has anyone else seen this happen after the handover of an opensource library where the paradigm shifts?