This repository was archived by the owner on Dec 9, 2025. It is now read-only.
Repository navigation
Replies: 1 comment
|
I think that even if the services like crowdin/lokalise are not decentralized, if we manage them and the access from the Aave DAO it could solve 2 and 3. The DAO could have the principal access to the service, and the rights to add / remove translators. I think there are also services that have free plans for opensource projects, and there are also opensource translation projects that could be deployed and managed by the DAO. We could implement a flow where:
This would make it so, the Aave UI has up to date translations, and that there is enough interest from the community to add new languages, as the translations would be incentivized. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There's currently a pr pending #125
gujaratiOn top of that there's a governance proposal to add
Swahili,Arab,Hausa/Yoruba,Pidgin- addinggermanwas also brought up somewhere.While localization is nice I think there are some technical/maintenance things to consider here.
1. Bundle size
The aave-ui is already quite "fat" and currently all languages are loaded for all users. So adding a new language adds bloat to all users. I think this is a solvable problem, but it needs to be solved before adding new languages.
2. Which languages to support
There's no analytics for the aave-ui as it's on ipfs, so there's 0 knowledge about where people use aave-ui from, nor can I know if people use the language selection at all. That said it's hard to make a choice on "is a language worth to be listed or not"(even for the already existing languages). I don't have an idea on how to solve this.
3. Language maintenance
The aave-ui evolves almost daily.
Adding a language today, does mean it has to be maintained tomorrow or it will quickly turn useless as there will be translation gaps everywhere. I think the current github based setup is not really suitable for crowd-sourced translations and the current amount of maintainers lacks time & skills to maintain languages. With a growing list of supported locales we need a solution to crowd-source the localisation effort.
Possible Solution
Perhaps one could use a service like crowdin/locize or similar to onboard non technical users into localization. Perhaps there's some more decentralized solution as all services i found require user management/ invite - i'm not an expert on that field.
This would help with 3) at least, but for 2) we're in the dark. One could do a snapshot vote on which languages to support on the ui to collect some info on the topic - not sure how helpful this would be though.
If i find some time, i'll work on 1) because it makes sense either way.
Would love feedback/ ideas on 2-3 though!
All reactions