Email accounts

This is how to translate account requests and user control panel

Translation of email registration and user control panel interface

Here you will find information on how the translation of email registration and the user control panel are handled.

What this is

When you request an email account at Riseup (this is reached by clicking the "Request account"), and when you change your configuration settings in the user control panel, you can view these pages in different localized languages.

How translation is done

  1. You must first have a Riseup email address
  2. Once you do, you need to request ‘translator’ status to be given to your account. That request can be done through emailing, or through a help ticket
  3. Once you have that status, you will login to the user control panel and on the left side you will see a Translations icon. Click this button.
  4. Now select your language from the tabs at the top. Make sure not to skip this step, which could overwrite the translations in English or another language.
  5. You will now see strings of words that need to be translated and strings that have been translated into your language.
  6. To only see strings that need translation, click the ‘Untranslated only’ box, then click the search button.
  7. To translate the string into your language, click the untranslated link and then fill in the translation of that string.

Special buttons

Clear translation cache
The translations are stored in the database and then cached in memory. This means that if you change an already existing translation, the in-memory cache remains. This sucks, and it should expire the cache when you make a change. However, the cache is broken in the version of Globalize we are using. So, if you change an already translated string it will be cached in memory and in order to see the changes take effect you need to click the “clear translation cache” button.

Delete untranslated keys
Every time the application encounters new strings in the process of running the application these strings are added to the database to be translated. Suppose I wrote some code that had a link called “User Diretcory”. Once this change is used by someone on the production site, the database will forever have an entry for the string “User Diretcory”, thinking that it needs to be translated. The only way to delete this key from the translation database would be to first fix the typo in the link and then click the button “delete untranslated keys”. This will remove all the strings from the translation database that don’t yet have translations. Ones that are still needed but haven’t been translated yet will get automatically added back to the database as they are encountered through the normal use of the application.


Currently, this translation effort is setup to handle: English, French, Russian, Spanish, Portugese, Italian, and Arabic.

Why do we not have other languages enabled by default? The collective decided to focus on en, es, and pt first: once we are able to support these languages then we can add more. To “support” means user interface, help tickets, and documentation.