New Websites translation workflow

Domingo Becker domingobecker at gmail.com
Thu Jan 31 16:55:14 UTC 2013


2013/1/31 Kévin Raymond <shaiton at fedoraproject.org>:
> Hi there,
>
> I would like to introduce you some changes that I am going to do on the
> Websites, that will change a bit the way your are managing the translations.
>
> It is not fixed yet, please give me your thoughts if you think that we need to
> improve some parts, remove others or just stick with my proposal.
> Don't be afraid, I won't introduce major changes! Oh wait, in fact I will (see
> point 5 if you don't want to read this email completly!)
>
> Here are the ideas, with an approximated schedule:
>
> 1. We have been pulling all translations twice hourly for years now from
> transifex.net (twice because we use staging). That is a slow process, and not
> really needed.
> Therefore we have started to only pull the translations daily, once (shared
> between stg and prod). This is effective only on staging actually, and will move
> to production soon. It is transparent on your side, but the fact that we pull
> the translations only once a day. You've been warned, now when you translate on
> transifex.net, it will only appear on the websites the day after.
> This could be moved to daily during string freeze, or a week before the
> release. Please tell us if it's needed (I don't think it's really needed but
> give your voice).
> Of course, if you've made a terrible mistake and something is bad on your
> translation, you'll need to wait untill the next day. This is bad. Try to think
> if it could happen. But you should really proofread your translations, and I am
> sure that you will never get this problem :)
> The POs files on the websites repository won't be used at build time. We get the
> POs directly from Transifex from inside our infrastructure.
> I need your help to check that it is working as it should. Please, translate on
> master, and proofread on stg.fedoraproject.org, spins.stg.fedoraproject.org,
> start.stg.fedoraproject.org and so on. I would like to be sure that with new
> POs it still work. (I can check it but your help is appreciated).
>
> (1.) Expected change by the 13th of Feb
>
> 2. Because the POs on the git repo won't be used at build time, they are
> probably going to be removed from the repo. Since Transifex keep an history and
> the push access are spread between teams, there should not be any really bad
> situation (like wrong language overriding). We could keep them here for the
> websites team, as we need to test some language build, but I think we will
> remove them shortly (as I have seen some commit on Transifex to enable pulling
> without being logged in).
>
> (2.) Expected change by the 13th of March
>
> 3. Our translation process at release time is not the best. We used to create
> alpha, beta and master branches for some websites (mainly fpo and spins.fpo) to
> let you translate and review the websites on stg before the release. To do this,
> we copyied the translations from the previous branch (master to alpha, alpha to
> beta and then beta to master) but doing this:
> * The maintainer get the translations credits by Transifex.
> * The string history is lost.
> * We are all lost because only people on the infra team could know where we are
>   pulling translations, and on which branch we build the websites.
>
> I already spoke about a new process months ago. Here is a formal introduction:
> * We will use only one Transifex resource per website.
> * Once we decide to prepare the websites for next release (alpha, beta, finale),
>   we will freeze the POs on prod (let's take as example alpha, if we are ready
>   to move to beta) and push the upcoming POT to the current release. You'll then
>   be able to translate the "new" website on the usual resource. You'll keep your
>   translation history, the credits etc.
> * At the release date (for example for beta), we will just enable again pulling
>   the POs which would be up to date.
>
> This does not change to much to you as we used to lock the translations during
> the freeze, to avoid lost of translations when moved to the next stage (i.e
> beta).
>
> Of course, we always try to avoid string freeze break, but again, we depend on
> marketing, docs, design, SIGs.. At every release we are making our websites
> stronger, which leads to more quality for you.
>
> (3.) Expected change for the F19 Alpha release
>

+1

Many branches for one release only confuses new translators. And
sometimes translations are lost.

For (1), how about twice a day updates for staging?

The Spanish Team proofreads translations in the staging website.

> 4. To let you work on new languages or new websites without loosing the visitors
> with a too light translation, we will start pulling only PO files translated at
> least with 30% of completion. Please tell me if 30% is too small, 50% could be
> fine but I am not sure if we want to make this websites dependant (like 50% of
> start.fpo Vs 50% of spins.fedoraproject.org).
> With this, a visitor won't be able to select the foo language is the website is
> not translated at more than 30% for this specific language.
> This is valide for production and staging, we won't be able to separate those
> because of the point 1. explained above.
>
> (4.) Expected change by the 13th of Feb
>

+1


> 5. There has been a good unknown Transifex feature for months now. The ability
> to review translations. I still don't like the way it is implemented: the
> maitainer (devs) has to choose for the translator the quality desired. No, it
> should come from the translation team. But let move this discussion on an other
> thread, later.
> Here, on the websites team, we are going to pull reviewed translations only.
> That is going to be a *huge* change for you. Therefore, we can probably enable
> this feature for specific teams only. I don't know yet how this would be set.
> Please every coordinators, tell me if this is something that you don't want for
> your team. The downside of this change is the need for your team to mark as
> reviewed all your translations.
> It could have changed (I did the feature request 3 or 4 months ago)- and don't
> ask me which ticket is it, I just can't track them all on their 3 different
> trackers) but here is how it works:
> * to review a string, you need to do it through the online translation tool
>   (Lotte) only. You can't authomatize that with the transifex client.
> * this is by-string or by-page process. You can't mark as review the whole
>   resource or project. I let you imagine how to mark as reviewed a project with
>   several rersources made of thousand of strings... Thanks to Transifex, the
>   hot feature is a pain to start with. That's mainly why we haven't used that
>   before, but I got the request to do so and it will add more quality to your
>   translations. I strongly hope the made something to help us starting.
> * only reviewers can review strings. So the language coordinators have to select
>   some reviewers. A reviewer is a translator that have one more power, the
>   hability to mark strings as reviewed. You can define them all as reviewers of
>   course.
>
> (5.) Expected change for the F19 Alpha release. But it really depends if we need
> to do this per language, and about your opinion. This is really the major change
> for you and we won't move forward on this topic if you don't want this for your
> team. That's why I need you to let me know if you don't want this. Yeah, if you
> don't reply for your team because you haven't read about this I will assume that
> you agreed :) We will choose the best solution for you!  (I shall probably send
> a reminder..)
>

-1

The Spanish Team decided to have this review feature disabled
(discussion at trans-es list starts at [1]).

[1] http://lists.fedoraproject.org/pipermail/trans-es/2013-January/001804.html

kind regards

Domingo Becker


More information about the trans mailing list