Last week Greg Koberger finally got me to cross “add a test locale to AMO” off my list – and it turns out it only took a few minutes of actual coding. It sounds like others have had some troubles so I wanted to run through what I did.
Firstly, you can see what I’m talking about at the AMO dev site. I’m using a script in the Translate Toolkit called podebug to generate a .po file filled with unicode characters. You can also generate one which surrounds the strings with “xxx” or blanks them out, etc. The goal is to easily see what strings on your website can’t be localized (this means they aren’t in the .po files for localizers).
If you’re using product-details to get locale names make sure you’re using the latest revision – I added dbg to the array so it will show up in language dropdowns like all the other languages. After that I added dbg to Django’s LANGUAGES define. At that point the language showed up, but we’d get tracebacks if we tried to format money in a string since ‘dbg’ was a fake language. AMO uses Babel for details about each locale so I just made a wrapper for the Babel Locale() function and told it to use ‘en’ if it saw ‘dbg’. This way ‘dbg’ is used for all the strings on the site but for any complex formatting we fall back to en. This works since dbg is based off en anyway, as far as pluralizations are concerned. You can see my commit which added that function and made sure we started using it here.
This also works on the marketplace.
 I actually added it to AMO_LANGUAGES which gets to LANGUAGES in a slightly round-about way. See our settings.py file for how that flow works.