-
-
Notifications
You must be signed in to change notification settings - Fork 384
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
Comments
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) |
I'd love your assistance in this - any help is always appreciated. |
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 |
@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": {
...
}
}
}
...
Just checked the project and everything seems ok. Have you expected something else? |
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. |
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:
Anyone can visit the page via the link
as the key, it would benote.sharing.public
or something like that.This would potentially also allow Notea to use something like Weblate or Crowdin, which could potentially make translations much easier to submit and edit.
The text was updated successfully, but these errors were encountered: