notea-org / notea

📒 Self hosted note taking app stored on S3

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Better internationalisation system

tecc opened this issue · comments

commented

Currently, internationalisation (i18n) is handled by taking the English translation and using that as the key, meaning that if the English translation is updated, every other locale needs to be updated as well.
That is not a sustainable system - it adds unnecessary ripple effects when updating translations.

A replacement is very much required, and I'd use the following solution:

  • make each key independent of language, so instead of Anyone can visit the page via the link as the key, it would be note.sharing.public or something like that.
  • remap the current locales to the new keys
  • make English a normal locale like every other

This would potentially also allow Notea to use something like Weblate or Crowdin, which could potentially make translations much easier to submit and edit.

Using some language-agnostic keys format instead of the English version of a string is definitely a more easy and comfortable way of managing localization strings.

Would be happy to help with the Crowdin integration. The localization process could be automated via native Crowdin GitHub connector or via the Crowdin GH Action (BTW, Crowdin can handle the current localization files as well)

commented

I'd love your assistance in this - any help is always appreciated.
The main issue right now, however, is replacing all the current keys and strings - which will take a lot of time. Based on a quick check there are about 117 (I may be wrong) unique keys to replace.

commented

Currently, I'm thinking of a structure similar to this:

{
    "actions.cancel": "Cancel",
    "actions.copy": "Copy to clipboard",
    "actions.delete": "Delete",
    "sidebar.tool.search": "Search in notes",
    "sidebar.tool.daily_notes": "Daily Notes",
    "page.action.create": "Create page",
    "page.action.create_subpage": "Add a page inside",
    "page.action.favourite": "Add to Favourites",
    "editor.actions.delete_column": "Delete column",
    "editor.actions.delete_image": "Delete image",
    "editor.actions.delete_row": "Delete row",
    "editor.actions.delete_table": "Delete table",
    "editor.nodes.code": "Code",
    "editor.nodes.code_block": "Code block",
    "editor.nodes.image": "Image",
    "settings.theme.light": "Light",
    "settings.theme.dark": "Dark"
}

(note: I mostly tried to arrange them in some sensible order, but for a real version they'd be sorted alphabetically preferably)

It's quite a simple format, although would it be better to have them as flat keys or nested objects? I'm leaning towards flat keys as it means less processing
Also, I tried to set up Crowdin already but it's not quite working as I want it to. This is the project I set up: https://crowdin.com/project/notea.

@tecc it could be either a flat or nested file structure. It's not affecting processing performance noticeably, don't worry about that.

Usually, it's useful to have some nested groups of stings if these strings are somehow related to each other (for example, some parts of the application)

For example:

...
    {
        "editor": {
            "actions": {
                ...
            },
            "nodes": {
                ...
            }
        }
    }
...

but it's not quite working as I want it to

Just checked the project and everything seems ok. Have you expected something else?

commented

Well, I was expecting the flat structure to have the keys work a bit better, but I got the result I wanted through the nested structure, so I'll choose that.
Either way the very long process of creating all the keys begins now.