Localization and future-proofing

Question

so I know this is a not a good question for the StackOverflow format. but I am at a bit of a loss, feel free to recommend a different place to put this where it may get some eyeballs

I am very familliar with the xgettext stuff for localizing your python program. currently we are saving user preferences as strings (eg: user_prefs = {'temperature':u'\u00b0C Fahrenheit', 'volumetric':'Cubic inches', ...} )

this works fine, and when operating in foreign languages we attempt(mostly successfully) to reverse the string localization back to english before saving it. so that the saved string is always the english version, and then we localize them when we start the program.

however it leads to problems later if we change 'Cubic inches' to u'in\u00b3' or even a small change like 'Cubic inches' to 'Cubic Inches'. we have somewhat compensated for this by always doing comparisons in lower case, but it feels hackish to me, and it seems like there must be a better way to do it such as saving an id (be it an index into an array or even just some unique identifier). but wondering about others experiences here with regards to future proofing user preferences so that they will always be recognized.

I suspect this will get closed (asking for subjective answers) but maybe I can get some good insight before it does

Answer 1

It sounds like you are trying to use the English representation of your text as a unique ID for the message, but then when you change the English representation, it no longer matches the IDs in your previously stored preference files. The solution is to use a unique and permanent ID for each message. This ID could be English-readable, but you have to commit to never changing it. It's probably helpful to use a simple and standardized naming convention for this ID, with no unicode or uppercase characters. For example, one message ID might be 'cubic inches'. Another could be 'degrees fahrenheit'

Then, you should define internationalized text for displaying this message in every language, including English. So if you want to display the 'cubic inches' message on an English system, you will lookup the English equivalent for this ID and get 'Cubic inches', 'Cubic Inches', u'in\u00b3' or whatever you like. Then your application can display that text. But you will always store the permanent message ID ('cubic inches') in the preferences file. This gives you the flexibility to change the English-language representation of the message, as shown to the user, without invalidating the IDs in previously-stored preference files.

Answer 2

i don't get your actual problem, where are you storing. but hope "base64 utf encoding decoding" can solve your problem.