Good question Enrico. For images and other non-i18n files, the intention is to have a special type of file (resource type) in Transifex, "Binary". This will either be 0% or 100% translated (no in-between) and the web editor would not open them, just offer download/upload. When the source file is updated (eg. English image), all of the translated versions of it are marked as untranslated.
This shouldn't be hard to support if required. Any additional material such as guides, source files etc should be put in a general-purpose VCS. -d On Wed, Sep 4, 2013 at 6:39 AM, Enrico Nicoletto <[email protected]> wrote: > Thank you for this very well explanation Dimitris. > > But when you said "Translators stay away from the VCS. They don't need > access to it any more" > I becamed confused because what happens if a translator needs to send the > locale version of an image? > (as some language teams do for documentations) or if we need to send our > locale version > of some audio files (for instance in GCompris)? > > Thanks a lot, Enrico. > ____________________________ > > Em 04/09/2013 00:34, Dimitris Glezos escreveu: > >> On 2 September 2013 15:50, Axel Hecht <[email protected]> wrote: >> >>> What process do you suggest in between transifex and version control? >>> >> I can only suggest what was worked with other projects and the rationale >> behind >> Tx's decisions. >> >> Based on what we've experienced with Django and other projects, the >> process >> could be fairly simple using the Transifex Client. I don't know if GNOME >> is >> ready for a setup like this, but here is what worked for other projects. >> >> >> ## Tx-git Bridge >> >> When a POT file changes, have the build system, git or cron push it to Tx. >> >> $ tx push --source >> >> Build systems or scripts are the most common. Developers can also do >> this manually when they want to (could be made part of the common >> Makefile across GNOME projects. >> >> When the software is ready to be packaged, have the build scripts pull >> the languages from Tx. >> >> $ tx pull --all >> >> For the pull, there a few options, like a) pull the translations only >> when the package is ready to be shipped (rel eng), b) commit them in >> the VCS too, but that's not necessary, c) use a cron job instead of a >> trigger to commit. >> >> >> ## Assumptions >> >> - You're using Tx as the canonical place where translations live. The >> VCS are for code. >> >> If you want to bypass this assumption, you'll need to also >> periodically push >> the translated files from the repo to Tx instead of just pulling. >> >> - The translators who want to work offline are not really attached to >> git, but >> rather the command-line. This is particularly tricky to convince >> people for. >> Most translators just want a way to mass-download and upload their >> files. So, >> they're OK to use Tx client to get their files and push them back. >> >> $ tx set --auto-remote <url> >> $ tx pull --lang pt_BR (downloads hundreds of files) >> $ tx push --lang pt_BR (uploads the ones modified) >> >> This, of course, is in addition to the options of using a web >> interface to >> DL/UL or actual access to git itself. >> >> >> ## Benefits >> >> - Translators have an online tool to work with a number of additional >> features, >> such as entity-level review, TM, Glossary etc. >> >> - Translators stay away from the VCS. They don't need access to it any >> more, >> and translation commits do not show up in the VCS history. >> >> - There are no merge conflicts. Tx handles them on an entity level. Source >> code line changes do not create issues, etc. >> >> Hope this helps. >> >> -d >> >> >> > ______________________________**_________________ > gnome-i18n mailing list > [email protected] > https://mail.gnome.org/**mailman/listinfo/gnome-i18n<https://mail.gnome.org/mailman/listinfo/gnome-i18n> > -- Dimitris Glezos Founder & CEO, Transifex https://www.transifex.com/
_______________________________________________ gnome-i18n mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-i18n
