Localization - .NET MAUI Hybrid + API + Translation Blazor server

Question

We have a .NET MAUI Hybrid app that needs translations. The usual way to do this is to use .resx files but based on our requirements they are not good enough.

Architecture:

• .NET MAUI Hybrid application for multiple platforms (ios, android) and in future the Blazor part will be extracted to pure web page as well
• API - ASP.NET Core API which stores translations in SQL Server database
• Blazor server admin page - after signing in, we have translation UI there to (manually or automatically) translate text to specified languages our app supports
• Shared lib project referenced in both .NET MAUI Hybrid and Blazor server

Our theoretical approach

• adhoc download - we dont want translations to be baked into app in build process, but when we edit something (e.g. some typo), client will fetch a new version on his app startup

• structure - the final translation JSON has a structure based on Pages and Components. Example:

  { "General":{ "Yes": "Yes", "No": "No", "Cancel": "Cancel" }, "Pages": { "Home": { "Title": "Home", "Statistics": "Statistics" }, "About": { "Title": "About", "Developers": "Developers" } }, "Components":{ "Header": { "Title": "Header", "Back": "Go back" }, "Footer": { "AllRightsReserved": "All rights reserved" } } }

• not to do typos on client (when calling localisation dict like L["Pages.Home.Title"]), we would like to use some class with pre-defined properties duplicating structure of the JSON. Example: In case I have HomePage.razor I will inject translation service that would contain: _translationService.Translations.Pages.Home.Title

Proposed flow:

• on Blazor server we create translation for a string of a client Page e.g. HomePage.razor
• after translating, the output is then saved to our database
• then this server page will take the whole translation structure and creates class-tree representing it and save it to the disk in Shared project (e.g. class Pages containing property Home of type HomePage containing string property Title)
• when client will request a language, the API will collect all translation records for specified language from dbs and creates the final translation json that will be cached for ~1h and returned to the client
• after client receives this language, it will fill the object from Shared project that was generated by Blazor server with translations received

Questions:

• Are we reinventing the wheel ?
• What do you think about this flow ?
• Is it optimal ? Or do you see there a place for some improvements ?
• Would it make sense to split it to some reusable parts and open-source it ?

Answer 1

I had a call with one Software architect and he didnt like this JSON idea.

The reason for me to reinvent the wheel was the lack of tools, because simple usage of .resx file is PITA.

I found that MS created some tool called Microsoft multilingual toolkit that should simplify it, but from a few videos I have seen, it looks horrible. On the other hand I got a recommendation for a tool called ResXManager. This tool was the missing part in our workflow.

So our new translation workflow is split into 2 parts:

• client-side translations - for text in app that doesnt change or is okay when it updates just after release. Usually page names, labels etc.
• dynamic translations - in our case exercise translations. We dont want to redeploy app each time when we add new exercise, so thats why the exercise translation is currently stored on API in .resx file. (still we have to redeploy API to make them available).

Summary:

• the client part is working great and is super-fast, because app doesnt have to ask API if there is a new language.
• the dynamic part not so much. It works okay but we have a few pain-points:
  • we have to redeploy api each time we add an exercise
    • this could be solved by some external storage for translation management (and versioning)
  • we have an admin panel (on web) where we create new exercises and their metadata, but to integrate ResXManager into our flow, we would have to download translations locally, do changes and uplaod them again because the ResXManager is just desktop app.

I will update this answer in case we found some flow improvements.

Answer 2

One of the very first things, that I have done about localization, was something very similar to this.

XML file, containing serialized dictionary, saved on Windows Mobile device, with code using NET Compact Framework 2.0.

It works. And this is the only good thing I can say about it.

You see, localization is not just some key-value pairs, that you store somewhere. Just because you see "Hallo" instead of "Hello", it does not mean that your app is now perfectly fit for German people.

At some point, I started to stick to what is generally used, working stable and easy to implement.

You are planning to do the opposite.

(This is opinion based, but your question leads that way anyway)