Hi FESCO

Could you please advise which date of the meeting is good for you all to talk on this request? We are based in Australia and would like to know in advance, so that we will stay awake. Or if another meeting is set up earlier time, it would be much appreciated.

How about our next meeting on 2014-08-27?

Yeah, the default is the regular meeting 2014-08-27.

Considering how inconvenient the time is, can we all first take a look at the proposal and discuss this in the ticket to see whether we even need to meet in the first place?

If we did need to meet, and wanted to change the meeting time, I’m not even sure in which direction to move it :)

Thanks, OK then, let's discuss on this ticket. We are open to any question, pls ask.[[BR]]

If we better meet in the future, moving either direction works (17:00UTC is 03:00AM in BNE).

I am afraid there is no direction that would work for the whole FESCo. If we move it earlier the FESCo members from America won't be able to attend and if we move it to a later time the FESCo members from Europe won't be able to attend.

Looking at [https://fedoraproject.org/wiki/L10N_Move_To_Zanata the plan]:

• At what point in the schedule does the go/no go decision happen? (AFAICT from the mailing lists, the l10n community overall supports the move, and I don’t expect FESCo would want to interfere in that decision; but looking into the technical details, can e.g. the filed bugs cause the move to be delayed or even aborted?)
• At what point do the upstream project maintainers need to be involved? Is it the “All projects complete migration to this new instance.” item? If so, we might want to schedule it so that this only 'starts' after the F21 final release is approved (~ a week before final release), to avoid interfering with fixing release blockers.
• Sort of speaking primarily for the upstream project maintainers’ side: Any idea how the migration process will look like? If it is something about as complex as “add project metadata on a web page, download a client, edit a config file for the client, tell the client to upload”, we don’t need to micromanage it at this level :) OTOH if it were significantly more complex, we might want to look into possibilities to automate/simplify before starting the migration process.
• The schedule implies that historical data will be migrated ''after'' all the projects have already been migrated. Can that really be done? This order seems a little unnatural. (OTOH to the extent it impacts primarily the translator’s credits, FESCo would probably be happy to leave this to the l10n team to worry about.)
• After an upstream projects switches, can we prevent further contributions to that project within Transifex to avoid losing future translators’ work / translators needlessly spending time creating a translation that won’t be used?

Replying to [comment:8 tmraz]:

I am afraid there is no direction that would work for the whole FESCo. If we move it earlier the FESCo members from America won't be able to attend and if we move it to a later time the FESCo members from Europe won't be able to attend.

Moving it an hour or so won’t help, but there are various options: e.g. move it 7 hours earlier, making it 12am for Europe, 6am for US East coast, and 8pm for Australia, under the theory that 6am is better than 3am. (FESCo members: Is the silence an indication that you are OK with the plan, or that you haven’t looked at it and we will end up discussing this in the meeting after all? Please speak up in the ticket or ''someone'' could have a meeting scheduled early in the morning and it just might be you ☺)

Replying to some of the questions by [comment:9 mitr]:

• Sort of speaking primarily for the upstream project maintainers’ side: Any idea how the migration process will look like? If it is something about as complex as “add project metadata on a web page, download a client, edit a config file for the client, tell the client to upload”, we don’t need to micromanage it at this level :) OTOH if it were significantly more complex, we might want to look into possibilities to automate/simplify before starting the migration process.

In the best case scenario that's all there would be to it: mainly creating a project in Zanata's web site, downloading the zanata client and configuring it (a base configuration can be downloaded from the site), and then pushing the files.

We (Zanata team) are planning on writing a wiki-style guide for the migration, and that coupled with the already existing documentation should help the move. We will also be available to offer more direct help during the migration process for any project maintainers that might need some special configuration or assistance.

• The schedule implies that historical data will be migrated ''after'' all the projects have already been migrated. Can that really be done? This order seems a little unnatural. (OTOH to the extent it impacts primarily the translator’s credits, FESCo would probably be happy to leave this to the l10n team to worry about.)

Zanata currently doesn't have a way to migrate the historical data. This has been brought up to the l10n team, and something would need to be implemented for this to happen if it's absolutely necessary. The other part of the equation is whether historical data can be pulled out of the current translation platform.

In terms of translator credits, it's my understanding that these are kept on the PO files as comments. If that's the case, Zanata will retain these comments. Additionally, as the files get translated via Zanata's web interface, the credits will be complemented with the names of the contributors from Zanata.

Thanks Carlos. [[BR]]
Here the answers for the rest.[[BR]][[BR]]

• At what point in the schedule does the go/no go decision happen? (AFAICT from the mailing lists, the l10n community overall supports the move, and I don’t expect FESCo would want to interfere in that decision; but looking into the technical details, can e.g. the filed bugs cause the move to be delayed or even aborted?)
  It should be the end of the test period. I will set certain date (01-Oct).[[BR]][[BR]]

• At what point do the upstream project maintainers need to be involved? Is it the “All projects complete migration to this new instance.” item? If so, we might want to schedule it so that this only 'starts' after the F21 final release is approved (~ a week before final release), to avoid interfering with fixing release blockers.
  ONE instance is ideal for us. It would be much appreciated if all projects can migrate to this new instance, so that translators can work on one place for everything. We will reset the start date to 'a week before final release' which is 2014-11-04 unless slip happens, with two months window. Can this fit the schedule?[[BR]]
  [[BR]]

• After an upstream projects switches, can we prevent further contributions to that project within Transifex to avoid losing future translators’ work / translators needlessly spending time creating a translation that won’t be used?
  I can not answer this, it should depend on the project owners and transifex team. I guess, prob, the project owners need to notify transifex to close their projects. Besides, I can make sure all language teams to switch to zanata and stop contributing in Transifex, once the migration completed. It would be nice if we know the date(s) of the migration for each project. If making blocks to group the projects and implementing the migration block by block with set dates can be done, it is easier for translators to know when to switch.[[BR]]
  [[BR]]

Replying to [comment:9 mitr]:

Moving it an hour or so won’t help, but there are various options: e.g. move it 7 hours earlier, making it 12am for Europe, 6am for US East coast, and 8pm for Australia, under the theory that 6am is better than 3am. (FESCo members: Is the silence an indication that you are OK with the plan, or that you haven’t looked at it and we will end up discussing this in the meeting after all? Please speak up in the ticket or ''someone'' could have a meeting scheduled early in the morning and it just might be you ☺)

I'm mostly supportive of this plan. My major concern is that we get this migration completed as much as possible before it becomes a hassle for F22 (I'm fairly sure we aren't going to change anything for F21 at this point). Beyond that, I think it's mostly up to the translation teams to implement and execute what they'd like to see from their tooling, etc.

agreed FESCo is fine with https://fedoraproject.org/wiki/L10N_Move_To_Zanata ; please schedule the upstream project migration to happen after F21 final release is approved. (+7,0,0)

Wishing Pootle was given a solid chance before such a critical decision was made. It's by far the most widely-used software (Mozilla, Openoffice, Evernote (http://translate.sourceforge.net/wiki/pootle/live_servers), actively maintained and truly open-source. Ah well. Best of luck!

As a main translator of Chinese (Taiwan) language, I support the move to Zanata after evaluating the platform via translating some projects. I found no big difference with offline translating which is my main translating way.

Replying to [comment:15 zerng07]:

As a main translator of Chinese (Taiwan) language, I support the move to Zanata after evaluating the platform via translating some projects. I found no big difference with offline translating which is my main translating way.

Thank you for supporting Zanata. Could you please discuss with all Chinese (Taiwan) translators and the coordinator, and reply the team's decision to [https://lists.fedoraproject.org/pipermail/trans/2014-August/011560.html this post] at trans list? Thank you again.