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
