feat: translations #662
feat: translations #662
Conversation
CyanVoxel
added
Type: Enhancement
…g untranslated stuff
|
Just a note, I would avoid renaming the keys if possible or else I don't think Weblate will know how to propagate those changes automatically. In f4b30c1 I had to update the keys across all translation files simultaneously before updating on the Weblate side. |
|
This PR is now ready for review |
| "menu.file": "&File", | ||
| "menu.help": "&Help", | ||
| "menu.macros.autofill": "Autofill", | ||
| "menu.macros.folders_to_tags": "Folders to Tags", | ||
| "menu.macros": "&Macros", | ||
| "menu.select": "Select", | ||
| "menu.tools": "Tools", | ||
| "menu.view": "View", | ||
| "menu.tools.fix_duplicate_files": "Fix Duplicate &Files", | ||
| "menu.tools.fix_unlinked_entries": "Fix &Unlinked Entries", | ||
| "menu.tools": "&Tools", | ||
| "menu.view": "&View", |
There was a problem hiding this comment.
I don't believe that alt (&) shortcuts for top-level menu items (File, View, etc.) will function, correct me if I'm wrong
There was a problem hiding this comment.
They work for me (for other languages you have to add the & obviously)
| "status.library_save_success": "Library Saved and Closed!", | ||
| "status.library_search_query": "Searching Library for", | ||
| "status.results_found": "{results.total_count} Results Found", | ||
| "status.library_search_query": "Searching Library...", |
There was a problem hiding this comment.
Note: In v9.4 the "Searching Library for" would be followed by the search query in the status bar, though currently I don't see the status bar being updated with this at all, even when trying to artificially slow them down. I'm fine with this change, though.
There was a problem hiding this comment.
Searching Library... gets shown for me (if only for a very short time).
In v9.4 the "Searching Library for" would be followed by the search query in the status bar
This changed in the Search PR as with the new search that would just mean repeating the query that is already in the search bar
| "ignore_list.mode.exclude": "Exclude", | ||
| "ignore_list.mode.include": "Include", | ||
| "ignore_list.mode.label": "List Mode", | ||
| "ignore_list.mode.label": "List Mode:", |
There was a problem hiding this comment.
Do you think it would be better to keep the colon out of the base translation then add it after the fact for any labels that benefit from it? To me I feel this would allow us to be more flexible with UI changes without needing to update the translations for things like this, but I'd like to get your thoughts.
There was a problem hiding this comment.
depends on whether colons are universally used in all languages (which I kind of doubt), because if not there would be some value in leaving that to translators. Code wise it is cleaner to leave it to the translation strings, but that's not really important besides maybe being a tie breaker
Implements Translation using the translation files from weblate. Also modifies
en.jsonwhen necessary.For testing go to
src/qt/translations.pyand either:Translations.change_language("<language of choice>")at the end of the file,return "???"in__getitem__.The first option should leave untranslated strings in Englisch while the second should replace every string that is effected by translations to
???.Notes:
preview_panel.pyisn't translated completely, mostly due to ongoing refactoring of that file in other placesClose #598.
Close #447.
Close #524.