On Wed, Oct 16, 2013 at 12:40 AM, Mathew R Odden <mrodden@us.ibm.com> wrote:
As requested in the last Oslo meeting, I created a blueprint for further discussion on the i18n work in Icehouse here:
https://blueprints.launchpad.net/oslo/+spec/i18n-messages
There were some ideas from the meeting that I'm sure I wasn't quite fully understanding, so please take a look and let me know if there is any feedback.
Hi, If I may include my 0.02€. I'm still trying to wrap my head around the need for translating API messages and log messages as IMHO it adds a lot more problems for app developers and log analysis tools, eg. a log analysis tool would be usable only for the locale it was developed for and break with _every_ update of the translations. As a translator myself I don't really want to check every system in existence if it uses my messages to do some sort analysis and often change the strings to more proper form in my language as reviews and feedback on the translation comes in - even though the original English string doesn't change at all. I feel that translating mostly computer facing stuff is just crying for bugs, weird issues popping up for users, API-s should be readable by humans, but translating them is a bit too far in my opinion. If I get it right the Message objects are supposed to move stuff around internally in a C/en locale, but we will still end up dropping translated messages to computers if the don't explicitly specify the locale which the request should use... Regards, -- Łukasz [DeeJay1] Jernaś P.S. Of course I may be wrong with all of that ;)