Before we open translations on weblate, I will take the current PO
files, for both the application strings and the user guide, and make
translation memory files out of them. I can then import them into
weblate (PO editor also supports TMX files in recent versions), and if
possible, translated segments from the old manual will be suggested in
the dtdocs translation. I don't have high hopes for a lot of matches,
since quite a bit of dtdocs has been rewritten, and translations just
don't work like that.
The other possibility is that we use machine translation for the first
round, then let translators edit that translation. We did machine
translation from one of AP's French articles to English, and I was not
impressed with the quality of the translation, but hey, we can always
give it another shot.
On 10/17/20 3:12 PM, jys wrote:
On Sat, Oct 17, 2020, at 09:34, Pascal Obry wrote:
Probably a good move and I understand that rewording was needed but
that it is tad harsh for translators.
I may be optimistic/wrong here, but the situation for translators may not be
quite as bad as it sounds. From the parts of the re-worked docs that I looked
at, the emphasis has been on making the language resemble compact native
English. Assuming that translators tend to do the same when writing their own
native language, there may not be much need for changes overall. Translators
would need to scan for *semantic* changes, and hopefully most of these would be
related to updated information, which they would already need to deal with
anyway.
That's my main concerns. Having the doc "away" from main repo will not
help. I don't know why exactly, but I've seen that on different
projects. Maybe because the doc is away it feels less part of the
project and there is less incentive to care for it?
Again, possibly optimistic, but the new setup has a distinct advantage in that text can
now be easily edited even within the github web interface itself, reducing the need for
contributors to maintain a local git repository just to "scratch an itch"
regarding updates or other improvements. In a sense, some technical burden has been
shifted to the maintainers of the repo, who will need to sift through (possibly many)
issue reports and accept (or not) PRs, perform any needed copy editing, etc... but they
seem willing to do this. :-)
___________________________________________________________________________
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
