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

i18n #99

Open
ThomasWaldmann opened this Issue Dec 21, 2018 · 9 comments

Comments

Projects
None yet
4 participants
@ThomasWaldmann
Copy link
Collaborator

ThomasWaldmann commented Dec 21, 2018

recently showed borg at the local linux user group, it was well received, some people prefer gui to cli tools, so vorta is just what they waited for.

but, first question of one of the guys: "gibt's das auch auf Deutsch?" ("is this also available in German?") and i had to tell "no, not yet".

so, while i18n for borg is rather optional, because UNIX admins hacking stuff on the cli usually also speak English rather well, it's a different story for the target audience of vorta - we need i18n for them.

so, what needs to be done:

  • code needs to prepared for i18n, gettext style _('english phrase') == 'german phrase' (for example). initially the _ function can be just an identity dummy until we have added the rest (e.g. the babel library). packaging also needs to be adapted to include the i18n files.

  • layout needs to cope with shorter / longer texts flexibly, so nothing gets truncated and layout still looks reasonable somehow.

  • UI needs to be as self-explaining as possible (because I guess we do not want to translate the docs also).

  • the english original text should be exported (to the .pot file) and spell and grammar checked by a good native speaker. if we have to change original texts, all translators will have to update their translations, so better do this before it gets to the translators. agreeing on some terminology and checking for consistency everywhere is also useful (e.g. don't call it archive here and snapshot there if you mean the same thing).

  • we need actual translations and infrastructure for translators, transifex is a nice service for that and free for FOSS projects. there need to be some scripts pushing / pulling stuff from/to transifex and this needs to be integrated into release process.

  • there should be a quality policy for the translations, like e.g.:

    • no google translate or other automated translation [of course]
    • only human native or as-good-as-native speakers, should be users of vorta (one-time translations are not that helpful if there is noone updating them regularly as needed)
    • must have >90% translated strings or language will be made unavailable in next release (this will help to motivate past or future translators). ideally there is also a notifcation service to send notifies to translators if their translation needs more work.
  • for even more fun, we could add support for rtl languages later.

@m3nu

This comment has been minimized.

Copy link
Contributor

m3nu commented Dec 21, 2018

Feared this would come up eventually. I know the process from large-scale website translations, I've organized in the past. Was always good fun.

I'll see if there are any blockers, like the Qt UI-files. Then start marking and extracting strings for translation.

@m3nu m3nu added this to the v0.6.z Branch milestone Dec 25, 2018

@brokenpip3

This comment has been minimized.

Copy link

brokenpip3 commented Dec 25, 2018

Sign me for Italian translation 👍

@genma

This comment has been minimized.

Copy link

genma commented Dec 31, 2018

Count me in for French translation 👍

@m3nu

This comment has been minimized.

Copy link
Contributor

m3nu commented Dec 31, 2018

Thanks, already noted. Hehe.

@m3nu m3nu added the help wanted label Jan 4, 2019

@ThomasWaldmann ThomasWaldmann self-assigned this Jan 15, 2019

@ThomasWaldmann

This comment has been minimized.

Copy link
Collaborator

ThomasWaldmann commented Jan 15, 2019

I'll try doing some work on this. No experience yet with any qt-specific stuff related to this (if any).

@ThomasWaldmann

This comment has been minimized.

Copy link
Collaborator

ThomasWaldmann commented Jan 15, 2019

First slight issue I've found is that py36+ f-strings are not really compatible with using a translation function, like _(f'foo: {foo}') - the func would get the already expanded string.

https://docs.djangoproject.com/en/2.1/topics/i18n/translation/ : it looks like only the %(foo)s formatting placeholder style is supported.

So:

  • get rid of all f-strings in translatable text?
  • get rid of all f-strings? this would maybe allow to support py35.
@ThomasWaldmann

This comment has been minimized.

@ThomasWaldmann

This comment has been minimized.

Copy link
Collaborator

ThomasWaldmann commented Jan 16, 2019

hmm, slightly confused.

is qt doing its whole own thing concerning translations and not integrating into the usual gettext-style .po files?

how to deal with all the texts in the .ui files? is the extracted text converted to .po?
if yes, how?
if not, will there be .po files for the python strings and .ts files for the qt stuff?

@m3nu

This comment has been minimized.

Copy link
Contributor

m3nu commented Jan 16, 2019

The QT C++ docs don't always fully apply to PyQt. For translations, the workflow seems roughly like this:

  1. Extract translatable strings into .ts files using the lupdate command. Then compile them to .qm files using the lrelease command.[1]
  2. Then use the QTranslator class to load .qm files from for a specific language from a path: translator.load("qt_ru", PATH)
  3. Add the QTranslator instance to the app: app.installTranslator(translator)

I didn't test this yet, but found some examples on SO.[2, 3]

This takes care of the Qt UI files. for strings in ordinary Python files, the workflow will be slightly different. Hope we can still use a common format to have all translations in one place. Regarding f-strings, they may be complementary. I.e. first pull the translated string. Then fill the data by evaluating the translated string as f-string. There could also be a helper-function that does both – takes an English string, translates it if needed and fills in some data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment