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!

Autark Flock Proposal
Autark Flock Proposal

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

AGP discussion: Community Funding DAO

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.


@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?


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…


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.).