We are hoping to use our Althea Aragon app in the network in Medellin, Colombia and would appreciate internationalization. We are hoping to use this within the next month.
Just hoping to keep this on the radar - thanks!


To add a little more detail about what I believe would be required: We can easily implement internationalization in our own app, but that leaves the apps like Finance, Voting, etc. in English. Even if these apps had their own internationalization, it would still be a pain for the user to have to go through them all and switch them over one by one. And of course there are items in the interface that are not part of any app.


100% support this… We should remove any hard-coded display text in Aragon apps (or non-apps) and have a language repository somewhere where new language packs for Aragon can be managed. I think an organization like the Aragon Cooperative can help manage the pull requests into the repository and deployment to IPFS.

Then under the “Settings” app in Aragon’s left-navigation menu, the user should be able to choose their language based on the available language packs and this will change it for all of the base Aragon apps and UI components, in addition to external apps that have adopted the standards.

Internationalization is in Autark’s roadmap, although at the moment the initial features to support this vision is in our nice to have list. We also want to modify Aragon to support right-to-left languages which will require flipping the UI.


Can’t wait to see Spanish supported :smiley: So glad this is on your Roadmap @stellarmagnet


Curious if someone with a bit more technical insight can comment on how technically challenging this would be. Is this something we could bounty?

@sohkai @jorge

1 Like

I think it requires the following (without not having followed to much on all of the components of Aragon recently):

  • Adding a setting in the dapp to change the language
  • Actually translating the current apps and the “wrapper” or w/e the correct terminology is now in respects to their front-end
  • Changes in Aragon.js to propogate the current language to apps
    • A neat thing here would probably also to have some guidelines and/or components in aragonUI for internationalisation
  • Internationalising Radspec.
    • I think this is the most challenging (whereas the others are still pretty time consuming), since Radspec strings are inlined in source code. I’m not sure if Solidity ever added vendor-specific tags to comments or if that’s still a Soon™️ thing, but if they did, then that would probably be the place to add multiple languages.
    • To be clear, this is both in Radspec itself and having to go over aragonOS and all Aragon apps and translating the Radspec strings directly in source. Requires a new version of each app and aOS (AFAIK)

Wow, I hadn’t thought of this. That is very challenging.

1 Like

@onbjerg With respect to radspec, perhaps this is another justification for moving the radspec strings out of inline source and instead into various radspec function registries?

1 Like

Yes, even more so it is going to be a huge hassle adding new languages to apps without a Radspec registry of sorts.

I think there is a scheme somewhere in an ERC relating to NFTs (I thought it was ERC721) that described how to internationalise using IPFS. I can’t find it for some reason, maybe it was discarded…

1 Like

Sharing this here as a potential resource:

Also I know internationalization is established terminology, but humbly propose that we refer to this broader effort as “globalization” or “translations” instead, which would encompass both internationalization and localization efforts (both of which are important but distinct activities supporting the even broader goal of accessibility). Just an idea, no strong feelings either way.


Mostly this is just a time-consuming endeavour that will need to be prioritized in terms of the product roadmap for the Aragon client. Building in the API in aragon.js to propagate the selected language to apps is technically easy and supporting internationalization (i18n) in React apps is not technically challenging for the most part.

This is something more challenging design-wise, especially with respect to icons. You don’t want to know what it’s like trying to translate a frontend into German. I’ve seen (larger) organizations spend entire years on i18n.

On Radspec internationalization, one way to get out of the hole of attaching the translations directly in the contracts themselves (let’s be honest: no one looking for internationalization is going to be looking at the contract source anyway), is to use the concept of lookup keys. This is already common in normal i18n strategies, where you specify a piece of text with a unique key, and could be applied to Radspec strings easily through hashes of the source radspec string.

The client would take the string, hash it, and then look it up in the i18n pack associated with the app (committed to IPFS with the app’s repo, through a centralized service provider, etc.).


About Radspec globalization, one easiest solution to implement I see (assuming aragonOS localization capability has been resolved), is to use the same syntax as in doxygen, using ISO 639-1 codes for languages :

 * @notice \~en This is an explanation in English. \~fr Ceci est une explication en français. 
function someFunct() {

I think smart contracts should remain fully auditable without relying on a externally served resources, like a i18n table.

About the more global effort to render AragonOS fully localizable – thus, not only languages, but also notation conventions (financial numbers, dates, etc.) --, I will follow with great interest any initiative in this direction.
We have a potential interest from a regional government to run a DAO for community projects. Cannot tell much more at this point, but it’s very likely that Aragon will be chosen for the initial experiments. Partial funding for the translations / globalization efforts could maybe come from that project, as proposing a english-only UI to the population wouldn’t be an option.

(This project is also related to why we’re currently trying to build this, and as we were writing all the app’s onboarding UI in french, I started to look for current globalization efforts for AragonOS…)

I imagine the radspec @notice would get pretty unwieldy if we kept it all on the contract, especially if we supported 3-5+ languages, hence the suggestion to serve this as alternative metadata published with the app (still content-addressed in IPFS).

Auditing a contract and providing human-readable descriptions of actions are very orthogonal efforts. Although auditors are usually helped by human-readable descriptions for additional context and understanding of what code is supposed to do, at the end of the day, the code speaks for itself.


@sembrestels and his team have developed a solution for this some weeks ago in the Ethereum Madrid hackathon last month, have a look:


Is Internationalization going to become a part of any Working Group?

Most likely the Product Working Group first, as we need to build out the infrastructure first.

Afterwards, it may become more of a community-driven project based on translation contributions and etc.