Intertnet Identity Multi-Language Support

Do you have any plan to offer multiple languages ​​support for Internet Identity UI, such as Spanish, French, Chinese, etc.

1 Like

The UI is partially ready for multiple language support. We would need to finish the support to all pages.

Unfortunately, this is not a priority at the moment. I hope that when the team has more capacity we can take this on.

Thank you for your response. While it’s great to hear that the UI has partial support for multiple languages, the lack of full localization remains a significant barrier to onboarding and credential provisioning. Users who are not fluent in the available languages may struggle to navigate the interface, impacting accessibility and adoption. Expanding language support would enhance inclusivity and encourage broader participation.

Understanding that priorities are in place, is there an opportunity for the community to contribute translations for key UI elements, such as those used for establishing an Internet Identity and the login screen?

1 Like

This question also is what I am facing right now.

We have adopted Internet Identity as our account system, so non-English speaking users will encounter a significant barrier right at the first step of our software, as the pop-up Inernet Identity window doesn’t display their native language.

1 Like

As an alternative. Can I clone the Internet Identity code, add multi-language support, and deploy my own version of Inernet Identity frontend?

Yes, you can deploy your own Internet Identity fork.

However, this will mean that those users will stay in that fork forever. They won’t be migrateable to Internet Identity.

If the community pushes hard for this, I don’t see how we couldn’t prioritize it for this year at least.

Would that work for you @edwardzhan @northman ? Which languages are the ones that you have most need for at the moment?

1 Like

Deployment would required English and French.

1 Like

We most need Spanish

1 Like

I think there is no migration problem if I just deploy the II frontend. because the user data still be kept in your backend canister.

2 Likes

That might need some more tweaking than you might expect. II is a follows a one canister architecture where the canister id is set on init. You will need to find that out and change it for the production II canister id.

We can help you if you have any problems. You can also try the “migration” by pointing your application to both frontends and see if you get the same principal.

The other annoying think is that you’ll need to rebase and redeploy when we add new functionality.

Apart from this, I think it could work. But I would test it before. We haven’t tried that directly.

1 Like

Thanks for your reply. Acturally, I am not really understand the complexity. As you say could you try about the way I proposed?

Exactly the perfact solution is that multi language is offered officially. If you could not prioritize it in this year. As a alternative, we hope self deployment is worked.

It is really a big trouble for us to push the product to the target market.

We just need Spanish now.

If you want it in spanish, you would anyway need to do a fork with the translations.

If you want to deploy it yourself and point to the production canister, you need to change the canister id that the frontend uses. It’s this line. This line points the frontend to the same canister. If you change this, you can point the frontend assets to any other canister.

I’m sorry, but it’s not only up to me to decide the priorities.

$ dfx canister create internet_identity --ic
Error: Canister 'internet_identity' is a remote canister on network 'ic', and cannot be created from here.

This error occurred when I deployed my own compiled Internet Identity

config in dfx.json is:

{
  "canisters": {
    "internet_identity": {
      "candid": "ii/original/internet_identity.did",
      "frontend": {},
      "remote": {
        "id": {
          "ic": "rdmx6-jaaaa-aaaaa-aaadq-cai"
        }
      },
      "type": "custom",
      "wasm": "ii/original/internet_identity.wasm.gz"
    }
    ...
}
}

This means “this canister is controlled by someone else on the ic network. Do not deploy it there.” If you remove the remote section the canister will be deployed. You probably also want to rm canister_ids.json since otherwise dfx will assume you want to deploy to the original II canister

1 Like

I’m head of Product & Marketing for the project EdwardZhan is working on so thank you for the helpful feedback - he’s making great progress toward a solution we can work with going forward.

My follow on question is to ask if there’s any interest in providing II account related functionality as a service so the UI can be completely customized by the integrating partner? My background as a Product Manager is primarily backend, SOA type of products and it’s common to offload this type of functionality through a robust, highly reusable service where user flows, localization and other UX side work is pushed to the application devpt team.

FWIW - If there is interest and I can somehow help with requirements we’d be happy to give back to the ICP effort in that area. Perhaps I could draft a proposal for review or talk with a team member to see where this line of thinking might go.

(I emailed Marco Walz with this idea and he thought it would be good to bring it up in this forum and context - in case there is interest and I can follow up with some help on this like of thinking)

I think Dfinity needs to proritize this given the discussions on sovereign tech funding and the need for EU independence from US based platforms. This is a serious obstacle for adoption. Multi-lingual support is critical for the identity and login workflows.

Time is of the essence. Not 6 months from now.