Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better internationalisation system #153

Open
tecc opened this issue Nov 28, 2022 · 5 comments
Open

Better internationalisation system #153

tecc opened this issue Nov 28, 2022 · 5 comments
Labels
enhancement New feature or request i18n Relating to localisations and translations

Comments

@tecc
Copy link
Member

tecc commented Nov 28, 2022

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.

@tecc tecc added enhancement New feature or request i18n Relating to localisations and translations labels Nov 28, 2022
@andrii-bodnar
Copy link

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)

@tecc
Copy link
Member Author

tecc commented Nov 28, 2022

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.

@tecc tecc pinned this issue Nov 28, 2022
@tecc
Copy link
Member Author

tecc commented Nov 29, 2022

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.

@andrii-bodnar
Copy link

@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?

@tecc
Copy link
Member Author

tecc commented Nov 29, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request i18n Relating to localisations and translations
Projects
None yet
Development

No branches or pull requests

2 participants