You are mostly right. With the current localization API it is possible to use arbitrary numbers instead of english strings to do the lookup. This has some drawbacks, however : first, its not really practical for the app developper, and second, if there is no translation catalog available, everything will be replaced by empty strings, making the app unuseable. The idea is not to get a universal system with a global lookup, there is a separation by application, context and comment. The global system will only be used for small words you usually find alone on a button. I agree that some of them may use the same word in english and need diffreent words in other languages, so the idea was to use constants like LOCALIZED_CANCEL_BUTTON_TEXT and LOCALIZED_CANCEL_MENU_TEXT (well, if a "cancel" menu makes sense at all). This is why I asked everyone to think about it. Each of us has different experiences depending on the language he knows, each of us can contribute to build a small list of words that needs to be translated globally. I want the translations to be as good as the original english version of Haiku, In the english version there are some things you find in multiple places (like the "Revert" word) and it seems a good idea to keep this uniformity in other places, even if there may be some distinction in other languages. This may even help improve and clean up the english wording from some ambiguities. Also, note the localization system is language-neutral, the jamrules allow you to have sourcecode in any language if you don't want english, and even if the master catalog extracted from the sourcecode is a bit special (it's the master reference), it is possible to look at the other catalogs and use one of them as a base for your translation if you don't want to use the master one. The locale kit does the lookup of strings even for english, it will not bypass anything. So, it will always be possible not to use the default translation in some case. And I hope the translators will hint the developpers when such a case happens. -- Adrien.