Thank you Hubert -- I hadn't realized that a considerable part of the manual was already rewritten.
I'll wait for the new translation workflow then! J. Hubert Kowalski <johnny...@gmail.com> writes: > Hi Jeronimo, > > Take a look at https://elstoc.github.io/dtdocs/ - as you'll see the manual > there is reworded to be more concise and to the point without additional > fluff and all contributors so far took measures to ensure that language is > clear english (both maintainers are native english speakers), which IMO > makes it perfect for translation. That however comes at a cost of having to > reword/retranslate parts of manual. > > wt., 20 paź 2020 o 18:00 Jeronimo Pellegrini <j...@aleph0.info> napisał(a): > >> Hi Mica, >> >> Thank you for the work on getting a more modern translation >> system. (And I'm really happy to see that Weblate is licensed as >> GPLv3!) >> >> I would certainly want to still work with Emacs; not necessarily >> with .po files. Just something that has an Emacs mode... >> (I'm willing to help write an Emacs mode, so long as I don't >> do that alone, because I'm quite overworked. I do have some >> experience with Emacs Lisp.) >> >> If I need to change to a different format and use a special >> update-weblate tool, that's ok! >> >> When you mention that part of the manual needs to be retranslated >> because it was rewritten, do you mean the parts that were changed >> in recent commits in git/master? If it is so, then I've been >> translating those as they come, and the whole thing should be >> up to date -- I hope. >> Or are those changes somewhere else (another git branch)? >> >> J. >> >> Mica Semrick <m...@silentumbrella.com> writes: >> > Hi Jeronimo, >> > >> > Thank you for your all your work; last I had looked br_PT was the most >> > up-to-date. >> > >> > We haven't really defined exactly what the translation workflow will >> > look like, but if we get feedback from translators that they still want >> > to work with PO files, I know we can certainly accommodate that. >> > >> > Weblate can do nice things like use and keep a translation memory, >> > leverage machine translation, and who knows what else; I haven't had >> > time to fully dive into it yet. I am not aware of what emacs can do. >> > >> > I think a decent portion of the manual would need to be retranslated, as >> > a good chunk of it has been rewritten. As I mentioned previously, I can >> > make translation memories from the current PO files and import them into >> > weblate or make them available to you via some other means. Since there >> > are a lot of new writings, I don't think that the old translations will >> > match up very well. I'm open to exploring machine translation for a >> > first pass if you'd like to do that. >> > >> > I'm also open to any other suggestions you may have. >> > >> > Best, >> > Mica >> > >> > >> > On 10/19/20 3:44 AM, Jeronimo Pellegrini wrote: >> >> 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 >> >> >> > >> ___________________________________________________________________________ >> > 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 >> >> > > -- > Pozdrawiam, > Hubert Kowalski ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
