I think the user groups of IC come from multiple countries, and the users who use NNS also come from different regions. It would be a very good function if NNS can support multi-language switching. The translation function of the browser may be inaccurate. I hope the community can add multi-language support
2 Likes
We, the team that implements NNS-dapp and II, definitely like the idea to support multi-languages.
Technically, on its core, NNS-dapp is even already all set to handle multi-language switching. When it comes to II, it’s in the backlog as far as I know. We recently discussed that briefly with one colleague.
The technical part is something but, effectively translating the dapps with quality is another. For that particular initiative I have no ETA.
I forward your message to the team.
2 Likes
Given that the team is really short of time it would be really cool if the community could lead n this. Also we keep on trying to decentralize more but then get asked to do more work, which centralizes the development here. On the face of it, it looks as if this really doesn’t need deep technical knowledge. Sure, it is necessary to be careful with language to make sure that the concepts are transmitted accurately, but technically the barrier should not be all that high.
Would it be all that crazy to make a canister that would facilitate such a translation effort? What would such a canister look like? Users could log in and propose translations for each field. Other users could upvote or downvote answers to get a ranking. Maybe the canister could host a static (no functionality) version of the site so that users could see the translation in context. E.g. to avoid super long transltions if there just isnt enough space for long text in the UI. Is there a developer in the community who would be willing to build such a translation canister? It could be extended to work for other canisters as well, it doesn’t have to be built just for the NNS-dapp. There could also be rewards for translators and reviewers.
1 Like
I think proposals that are not technically difficult or even do not need to consider security issues can actually be implemented by the community through the bounty mechanism, which will not only increase the enthusiasm of the community but also reduce the pressure on the development team
2 Likes
This is still my recommendation:
Replacing hard-coded strings with formatted messages and add a locale file is indeed what we do in NNS-dapp and what we are discussing for II - i.e. it matches your recommendation in terms of development.
Using a third party JS library to do so on the contrary is excluded (I would say). We try to avoid pulling JS runtime dependencies when not abosultely needed (maintability, dependency, security and opinionated reason). NNS-dapp do not use third party libary for i18n.
Above suggestion of @bitdivine goes a bit more broader than code and I like the idea to look at this also from a higher prism level.
1 Like
I don’t want the “broader perspective” to slow down multi-language support though. I suspect that the absolute minimum viable solution is to have a language maintainer for each language. Text changes; if we want to keep up velocity we can’t wait a long time, when a text field changes, before the translations are updated to match and we can deploy. We could default each field to the English version, so we would deploy, some text would appear in English in all languages, then community members would contribute translations. Or we could provide a preview of every release and during the preview, the community and language maintainers in particular could propose updates to the text. Of course one language maintainer isn’t ideal but it would be enough to get this started.