Hello, (I sent this from an email address different from the one registered in the mailing list and it didn't seem to be sent, so I'm sendingit again from the correct email. Sorry for any duplicates)
I have been working on the pt_BR translation (of both darktable and its manual). I usually translate using po-mode in Emacs, but of course I can adapt to some extent. :) How much of my workflow would change? One thing that would be difficult for me is to translate directly on a web browser. I may be old-fashioned, but really, I never got to do any reasonable work on web interfaces. Will it still be possible to use an editor to do translation work? Also - would the darktable manual translation need to be re-entered or reworked? You mentioned that translated segments would be suggested, so I suppose the whole document would need to be entered again in weblate -- is this correct? Thanks, Jeronimo Mica Semrick <m...@silentumbrella.com> writes: > 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 ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
