Unique error codes sounds like a very good place to start!
Freezing the code while a hypothetical group of volunteers localizes sounds premature to me.
Are there good examples of projects with lazy localization that work well? EG The project is released in english, but there are sub-trees where additional localized content can be populated based on index numbers and such?
On Jul 1, 2011, at 8:38 AM, Steve Loughran wrote:
> On 01/07/2011 06:44, Owen O'Malley wrote:
>> On Thu, Jun 30, 2011 at 9:06 AM, Eric Baldeschwieler
>> <[EMAIL PROTECTED]>wrote:
>>> Do other apache projects have a good localization framework for error
>> Java has very good localization capabilities. However, it is a huge
>> pervasive change if we want to get each and every user-facing string
>> -- Owen
> Let's be precise: Internationalisation (note the spelling) is a
> maintenance mess too. It's not so much a "one off event" as something
> you have to do every time anyone adds an error message, or you gradually
> let the percentage of i18n'd messages drop over time. Given a limitation
> of Hadoop now is that when you get near the fringes of the valid
> configuration space the messages aren't that helpful, I'd focus on those.
> I say "I" literally here, as it tends to me that hits these problems.
> In a concession to the US installed base, I will spell words like
> "datacentre" and "normalised" incorrectly for EN_GB. This is not just
> politeness, it's self interest: I added a message to Ant about an
> unknown task that said "your task is spelt wrong", and we kept on
> getting bugreps saying "you have spelled spelled wrong" that I'd close
> as "workforme, you can't spell the past tense of spelled correctly",
> until I got bored and changed it to a present-tense form that was valid
> I18n getting started docs are good, and examples, but error messages may
> be best left as is. One possibility though is to add a unique error code
> to each one that could be indexed in each document, wiki, etc.