I18n #305
I18n #305
Conversation
this ensures strftime('%c') displays a localised date
we'll need to wrap all strings into gettext next
we also hook into the build a .mo generator
... which itself imported it from gameclock, which itself imported it from who knows?
it turns out that the _() function overlaps with our use of list
expansion constructs. i.e. this doesn't work:
_ = lambda x: x
def foo():
_('test')
a, _ = (1,2,3)
it raises a:
UnboundLocalError: local variable '_' referenced before assignment
so we use __() everywhere instead. _() is still available, but we
favor __() by default now.
that was a sucker to figure out.
|
It is a bit unfortunate that there was no discussion about translation before this changeset, because you invested quite some work in it and I think I'ld prefer not having any translation. translations are a burden and they tend to be outdated once the initial effort / passion is over. I know this from other projects, translations are always behind. sometimes, translations are even worse than just having stuff in english (that's why I have my system set to en-US to not having to bear with crappy german translations). Also, how many other UNIX commandline system tools do you know which speak something else than english to you? Where would translation start, where stop? Long commandline options are english, too. Exception messages? Do I have to speak french if I want to fully understand a traceback from a french locale using user? Do we need translated docs also, because the input/output of the program would be different? Sorry, but currently the effort needed to implement and maintain this seems to by far outweigh any positive effect this might have on some users. |
|
rpodgorny commented a day ago: unfortunately, i have to agree with thomas on this this one. in my experience, translations just suck. :-( |
|
btw, there is a famously hilarious example where translation has gone way too far: iirc visualbasic and also some "programming languages" used in other office/spreadsheet programs at some time were translated to german (and maybe other languages). I mean the keywords of the language... |
|
anarcat commented a day ago: i believe i understand your concerns. from what i understand you are concerned about translations for the following reasons:
Let me answer those concerns one by one. Burden of translationsTranslations can be a burden, it is true. Yet it is a little like the logging system: once the conversion is done, what we need to worry about is simply to wrap new user-visible strings in I think that, properly implemented and well integrated in the development workflow, the impact of this can be minimal while at the same time being beneficial to a larger community of users than english speakers. Harder diagnosticsI do not think that support will change much with translations. In backtraces, we see the original strings, so as long as there is a backtrace, we know exactly what is going on. Also there's a very easy way to turn off translations: just set LANG=C in the environment and we get native strings. Non-native english speaking collaborators are frequently confronted this problem and it's common for project to ask for bug reports with that environment. Finally, I think that translation can help users not have to submit bug reports, because they can have a better idea of what is going on if their software talks in their native language. Translations that go too far: what should be translated?I have also seen pretty funny examples of this, and it is true that translation can go too far! :) In my opinion, the translation model i propose doesn't go that far. What is translated?
What is not translated?
This should of course be documented in the development manual. Translations can be badThat is true: translations can be kind of bad and confusing. But the same could be said of error messages or even software in general. Some user interfaces are utterly confusing, error messages misleading or missing. Some software just doesn't work outside of their creator's laptop. That is obviously not a good reason not to write software or user interfaces. The same way, the fact that some translations are bad shouldn't keep us from offering the possibility for the translation community to provide excellent translations for borg. We can set standards for translation: it needs to be peer-reviewed, for example. We could set guidelines for translation of certain keywords. Ultimately, I don't believe that bad translations should be a deterrent to writing translation at all. Like everything in the project, it starts, grows and matures. And non-native speakers are fully aware of the english lingua franca (what an ironic word, btw) phenomenon and have to deal with it on a daily basis. Bad translation, for them, can be better than no translation at all. French was the lingua franca of the world between the 17th and 20th century: would you use borg if it was written in french? Of course not, and I would understand. Some people simply do not speak english and we should be able to reach out to them. The translation community can act as ambassadors and have done so for decades (if not as long as human languages existed, in fact). Limited benefits for the userI cannot disagree enough with the impression here that translations are not useful, per se. For me, borg should be a backup software that is accessible to a wider community of users than just sysadmins and developers. It is not, after all, our "pet project" is it? :) When software talks a foreign language, it alienates users that are not familiar with that language. We cannot assume that all our users speak will need to speak english to operate borg. One of the reasons free software is so successful is because it is so universal and talks to everyone on the planet, regardless of their origin or language. I also think that translations is a great way for non-programmers to get involved in the project, just like documentation, and can lead people to get interested in collaborating with the project that wouldn't normally have. I know it happened to me (now decades ago) and i am thankful for this the translation community of helping learn english all those years! :) Answers to specific questions
A lot! Most of the GNU utilities do, my web browser, my whole graphical interface, heck even the installer of my operating system (Debian) is translated into my native language. Heck, even git is translated, and here's a technical language for you... Translations for popular software is pretty good here (LANG=fr_CA). Although at some technical translations sometimes show up that are a little confusing, I believe I am better serving my community by using tools in my native language, for people that do not share my privilege of knowing more than my mother tongue.
I believe I have set good expectations above. Those could be detailed in the development documentation... (Long) commandline shouldn't be translated. In fact, I don't think I know of such software and that would be silly because it would break scripts based on locale, among other things.
Exception messages yes: when things crash, we want the user to know what is going on without having deep internal knowledge of the system, let alone in a foreign language... Of course, exception backtraces shouldn't (and probably couldn't meaningfully) be translated...
Fortunately, no: first, we should simply document that people need to submit bug reports in the
I think it would be a great idea to translate the documentation. In fact, I believe it's one of the reasons we switched to readthedocs.org, no? Again, I understand the concerns, and i also felt this daunting feeling when starting to translate my own projects. But when it is started, it is just part of the regular workflow. The impact is minimal and it means the software I write can reach a much wider community of users. Finally, I am sorry I didn't submit this idea before working on it offline. I had a bunch of ideas then and no internet access, so I just pounded at a few issues like this on my own. I hope that the implementation provided will show that it is possible to provide translations for borg easily and non-intrusively. Ultimately, if you do not want translations, keep your locale on |
|
Note: I moved the comments from the old PR to here. Everything appears to come from me due to this, but the orginal author is mention in the first line if it is not me. |
|
burden: it is way more than wrapping all strings in diagnostics: LANG=C doesn't help you if it wasn't configured like this and just happened once. of course we can read the traceback (if there is one), but if there is just an error message, would you like to deal with bug reports containing non-english error messages you can not understand? translation scope: good to agree about not translating commandline option long names. but isn't it feeling inconsistent then if you speak english to the tool and the tool speaks french to you? translation quality: often there isn't that much peer review (and as developers, we often would have to deal with translations we do not understand at all). I agree this is no fundamental argument against translations, but it is just a sad fact that there are many bad translations due to lack of qualified peer review. translation user benefits: if this were a GUI project, I'ld agree. But in fact it is a commandline tool and it requires root to do a full system backup - and that already limits the audience to users and system admins who know how to operate a commandline and deal with mostly english text user interfaces and docs. another thing that I didn't mention yet is priorities: we have quite a lot to fix aside from translation until borg works perfectly. by introducing translation, it will just slow down all the other efforts to make it a good working backup tool (see "burden"). there are also tools like borgweb that parse log output of borg (not too much yet due to the previously lacking logging mechanisms). having different languages in there isn't helpful for that at all. |
i don't think we need to deal with this ourselves necessarily. or, more precisely, you don't necessarily have to deal with this. it's just one other task that other people can deal with.
same here.
that is true..
that is a rather extreme case... which is handled pretty well with fr_CA vs fr_FR... which i have almost never seen as a distinction, but it's supported (ie. if fr_CA isn't available, i believe it fallsback to fr_FR).
i think we already handle this properly, or at least the logging module should. anyways, we have to deal with this problem when we display paths, for example...
i would defer that to the people that know those languages. :)
gettext deals with this.
so yeah, it's more work. but what i am proposing here is not to do all of this work ourselves. just patch the code base to enable others to do this. thus "just add
true, LANG=C won't work for one-time errors. But we yield so much tracebacks right now that it shouldn't be a problem. :) furthermore, i think this is a general problem we're having anyways: i believe we talked about this before, if we are not in verbose mode and an error happens, sometimes we don't know what's going on, period... stuff like the logbook module could help here, as it can stack notices and error messages and deliver them all of them in certain conditions (unexpected failures)... in other words, i believe this problem is more general than just translations, which are just a side effect...
no, it doesn't inconsistent. :) or rather, the convenience of having french translations outweighs the inconvenience of english commandline flags.
true. it's a problem. but i believe, like everything else, that it is something that stabilises over time. we can't expect to have this right the first time, but we can hope to have it converge to something pretty good overtime. i know, for example, that translations of larger projects like git and firefox are excellent, and i generally have no problems with translations, at least in french.
actually, we do support non-root backups now. users on a multi-user system can backup only their home directory, for example. we are working on a GUI, through the web interface, and i wouldn't exclude having a GTK or graphical frontend of some sort. if the commandline doesn't support translations, it makes all of this (future, granted) work much harder.
i am not sure of this. we are working in parallel here: you deal with pretty deep internals in borg, i work more on docs and usability, and the deeper stuff is currently way over my head (even though i do try to understand the internals, the implementation still escape me a little). i expect we could welcome way more contributors if we enable them to work with stuff like translations and documentation. the switch to RTD helped with docs, for example!
i'd be curious to understand better how this works, because in my mind, the translations shouldn't sit in borgweb, it should be in the backend, and borgweb should just set the right environment... i mean if we're going to have borgweb translated, how would it find strings to be translated? :) anyways, thanks a lot for the reply. i understand you're worried about the additional burden of dealing with all translations issues, but i am just proposing to have translatable strings in code. this is very similar to switching to the logging module: it enables a bunch more stuff (like syslog and so on), yet we haven't gone around to doing all of that yet (and we don't have to!). |
Personally I'd like to see Borg in other languages. I agree that translations may lag behind, not reflect the last commit, poor quality etc, but without even providing internal i18n hooks precludes Borg to have possibly good or very good translations (at least for --help). IMHO this is enough to justify the efforts.
I wonder how many users are some users. Seeing the amount of translated software, gui and command line, there should be good interest on that. |
|
We have to consider the type of user that uses borg. This changes when borg becomes available to more common PC-users. Something that will happen with time and when GUI applications pop up. I imagine https://github.com/borgbackup/borgweb together with a native Windows version will have such an effect. |
|
To have used numerous tools, I think it is useless to translate a command line tool such as borg. |
with this pull request, borg becomes translatable, basically: dates are displayed in the current locale, and gettext
.pofiles can be generated from the template to translate all user-visible strings.those strings were painstakingly selected by hand (actually with emacs
query-replace-regex's pattern:'\([^']*\)' -> _('\1')), and some may be missing, but i believe this is fairly complete.of course, the next step is to actually translate borg. this can be outsourced in a community effort, using something like weblate which works with git and gettext pretty transparently. i have used it with good success with monkeysign - this is how the tcheck and spanish translations got in! (oh and look at that, an italian translation too!
/me pulls:))this is a reroll of #287