| === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad-meeting | ||
| === carlos [n=carlos@138.Red-81-39-35.dynamicIP.rima-tde.net] has joined #launchpad-meeting | ||
| carlos | hi | 04:03 |
|---|---|---|
| SteveA | hi | 04:04 |
| SteveA | so, I have a call with mark in 1.5 hrs | 04:04 |
| SteveA | and I wanted to catch up with you on how 1.0 stuff is going, and any other issues that are around currently | 04:04 |
| carlos | Ok, they didn't changed too much since last time we talked | 04:05 |
| carlos | Danilo told me that firefox seems to be done | 04:05 |
| carlos | but he suggested a new way to handle file imports | 04:05 |
| carlos | to help with OO.org native imports | 04:05 |
| carlos | that get a single file as input and produces more than one template | 04:06 |
| SteveA | does firefox done mean the code is done, with tests? | 04:06 |
| SteveA | the code is in RF? | 04:06 |
| carlos | so we are able to have 1 file as input and n potemplate or pofile as output | 04:06 |
| SteveA | the code is committed to danilo's branch? | 04:06 |
| carlos | done means he's in testing stage | 04:06 |
| SteveA | so, not in RF | 04:07 |
| carlos | not yet | 04:07 |
| SteveA | but working prototype, pre review, on danilo's branch | 04:07 |
| carlos | I'm not quite sure whether his suggestion will require changes for firefox, we will have a meeting about it today | 04:07 |
| carlos | yeah | 04:07 |
| carlos | I think so | 04:07 |
| SteveA | a single file as input... | 04:07 |
| SteveA | what single file would that be? | 04:08 |
| SteveA | I'm trying to understand what you're describing | 04:08 |
| carlos | OpenOffice has all translations inside a single file per language | 04:08 |
| carlos | for documentation, oo-writer, etc | 04:08 |
| SteveA | ok | 04:08 |
| SteveA | so, I can see why we'd want to split that up | 04:09 |
| SteveA | is it obvious how to do that? | 04:09 |
| carlos | but Rosetta will not represent that as a single template because the amount of messages is huge | 04:09 |
| carlos | yeah, based on top directories where the sources are stored | 04:09 |
| carlos | we have such information inside the file we get | 04:09 |
| carlos | and it's more or less the same split we currently do with the .po bridge we use atm | 04:09 |
| SteveA | ok | 04:10 |
| SteveA | and, how does that help FF? | 04:10 |
| carlos | Well, that's something I need to discuss with danilo because the initial talk we had about this was more focused on OO.org and tarball uploads | 04:10 |
| carlos | I don't know exactly how would that affect FF | 04:11 |
| carlos | the thing is that most of the work for FF will be reused for OO.org so I guess he already saw that as an advantage for OO.org while working on the new Rosetta infrastructure changes (if FF is not affected) | 04:12 |
| SteveA | ok | 04:13 |
| carlos | about TranslationReview and the view restructuration that we talked about | 04:13 |
| carlos | I will have the meeting with danilo today | 04:14 |
| SteveA | so, you'll have an opinion about this tomorrow | 04:14 |
| carlos | as you suggested | 04:14 |
| carlos | yeah, I think so | 04:14 |
| carlos | after that, I will try to have a preimplementation call tomorrow to start with this as soon as possible | 04:15 |
| SteveA | what was the TranslationReview and the view restructuring? | 04:16 |
| SteveA | I don't remember it, bassed on those words along | 04:16 |
| SteveA | alone | 04:16 |
| carlos | TranslationReview is the UI that will allow our users to review translations much more easy, it's a 1.0 goal | 04:16 |
| SteveA | right | 04:17 |
| SteveA | but, what was the view restructuring for it? | 04:17 |
| carlos | view restructuring is a request I got from kiko and that I see as a good thing to do to finish TranslationReview implementation | 04:17 |
| carlos | that improves the way the views that use the translation form work and reuse code | 04:17 |
| SteveA | ok | 04:18 |
| carlos | because we have a couple of hacks to reuse POMsgSetView from POFileTranslateView | 04:18 |
| carlos | that at this point require more ugly hacks, kiko suggested a third class specific for the form that will not depend directly on POFile view or POMsgSet view | 04:19 |
| carlos | but on a list of POMSgSet objects that will have more than one entry when we have POFile as the context and just one item when we have POMsgSet as the context | 04:20 |
| carlos | anyway, this is not the final decision, it depends on what I agree with danilo and the reviewer from the preimplementation call | 04:20 |
| SteveA | ok. so, you're starting work on TranslationReview now? | 04:22 |
| carlos | no | 04:23 |
| carlos | that task is actually blocked on this | 04:23 |
| carlos | before being blocked | 04:23 |
| carlos | I already did most of the UI changes | 04:23 |
| SteveA | you're saying that TranslationReview is blocked on the view code refactoring? | 04:24 |
| carlos | and part of the view changes, that was the point when I was blocked looking on fixing the views | 04:24 |
| carlos | yes | 04:24 |
| carlos | I could finish TranslationReview spec | 04:24 |
| carlos | but that would require some hacks | 04:25 |
| carlos | that I would prefer to avoid and I think could be avoided with the restructuration | 04:25 |
| SteveA | "restructuring" | 04:25 |
| carlos | ok, thanks | 04:26 |
| carlos | you know, my spanglish... | 04:26 |
| carlos | about Edgy translations, we already imported most of the .pot files and I think we already fixed the translation domain changes since dapper release | 04:27 |
| carlos | this is not an official 1.0 goal, but it's an Edgy one | 04:28 |
| carlos | I sent an email last week about translations for documentation that are not part of language packs | 04:28 |
| carlos | would be really good if Mark answers that email | 04:28 |
| carlos | I sent it to launchpad@lists.canonical.com with the subject: "What to do with non language pack translations" | 04:29 |
| carlos | and that will help us to kill what we still have pending in the import queue (atm, 4800 entries) | 04:31 |
| carlos | we were importing those entries, but some Ubuntu developers complained to me about the fact that they are not being used at all so translator's efforts are completely wasted | 04:32 |
| SteveA | what are the translation domain changes? | 04:34 |
| carlos | some products use their version number as part of the translation domain so with a new release, it changes | 04:35 |
| carlos | and we need to detect those changes and apply them so language packs have the right info | 04:36 |
| carlos | for instance | 04:36 |
| carlos | for dapper, evolution used evolution-2.16 as the translation domain, with Edgy, it changed to 2.18 | 04:36 |
| carlos | I mean to evolution-2.18 | 04:36 |
| carlos | if we don't do that change, the application will be untranslated because it will not find the translations | 04:37 |
| SteveA | ok | 04:39 |
| carlos | Do you want to talk about other things that I was working on? or just the ones related with Edgy and 1.0 ? | 04:40 |
| SteveA | first, can we just summarize the conversation so far? | 04:41 |
| carlos | sure | 04:42 |
| carlos | - Firefox is in testing phase. Pending to see of the 1 file to n potemplates/pofiles mapping affects it | 04:43 |
| carlos | - TranslationReview is blocked on view changes that are blocked on a pending meeting with danilo and a reviewer (should be unblocked tomorrow) | 04:43 |
| carlos | - Edgy imports are mostly done, blocked on a final decision about whether we should import non language packs templates, if the answer is 'no' what should we do with what we already imported | 04:44 |
| carlos | I think that's all | 04:45 |
| SteveA | ok | 04:46 |
| SteveA | thanks, I like the way you produced a clear summary | 04:46 |
| SteveA | it helps me a lot | 04:46 |
| carlos | you are welcome | 04:47 |
| SteveA | what are the other non-1.0 things? | 04:47 |
| carlos | well, there were some bugs fixes and user support requests that I don't think we need to talk about | 04:47 |
| carlos | but, I detected a problem with Dapper language packs | 04:47 |
| carlos | we had a 'hole' of translations | 04:47 |
| carlos | that were not in the initial language packs and due a wrong timestamp are not part of the language packs updates | 04:48 |
| carlos | I think I detected all those files and agreed with Martin Pitt in a way to solve the situation | 04:48 |
| carlos | I'm going to prepare a brief summary to the mailing list | 04:49 |
| carlos | the problem was that the we had the wrong timestamp for the initial language pack for dapper, so it was around two days after final language pack for Dapper was released | 04:50 |
| carlos | and that prevented language packs updates to include the updates done in those dates | 04:50 |
| carlos | that's mainly koffice translations | 04:51 |
| SteveA | ok | 04:54 |
| SteveA | so koffice translations (mainly) missing in dapper langpacks | 04:54 |
| SteveA | because of a timestamp problem | 04:54 |
| SteveA | meaning that there were translations made after the initial langpack was shipped with dapper | 04:54 |
| SteveA | that were missed out of the updates | 04:54 |
| SteveA | is that right? | 04:54 |
| carlos | yeah | 04:55 |
| carlos | because those translations came from upstream | 04:55 |
| carlos | and no other ubuntu translator touched those pofiles | 04:55 |
| carlos | the plan to fix this is to 'touch' a translation in those pofiles to force a new export | 04:55 |
| SteveA | ok | 04:55 |
| SteveA | so, the fix is to "touch" a translation in each pofile with a hole | 04:56 |
| SteveA | force a new export | 04:56 |
| SteveA | and these will be in the next langpack update | 04:56 |
| SteveA | how did you find out about the problem? | 04:56 |
| carlos | yeah, that's the solution | 04:57 |
| carlos | because from time to time, a KUbuntu user complained to someone that then complained to me | 04:57 |
| carlos | until a couple of weeks ago | 04:57 |
| carlos | when a KDE developer that tracks our KDE translations | 04:58 |
| carlos | warn me about the problem and help me to debug it | 04:58 |
| carlos | previous complains came from GNOME users that were not able to help me with that | 04:58 |
| carlos | and after check some language packs, I detected the problem, after that I had to develop a script to compare all dates and after some manual review, got a list of files with this problem | 04:59 |
| carlos | I'm not 100% sure that I got all files, but I think that I got most of them | 04:59 |
| carlos | .po file format is really poor with version tracking | 05:00 |
| SteveA | ok | 05:03 |
| SteveA | do you know how the timestamp problem occurred in the first place? | 05:04 |
| SteveA | also, when you have a problem like this, please let me know that it has occurred | 05:04 |
| SteveA | it's the kind of thing someone may ask me about, and I'd feel stupid for not knowing | 05:04 |
| carlos | well, it was a mix of communication problem between Martin pitt and me and the fact that we use a mirror to export language packs | 05:05 |
| carlos | so I put there the wrong date | 05:06 |
| carlos | (we still do this manually once the final release is done) | 05:06 |
| SteveA | where did you put the wrong date? | 05:06 |
| carlos | I thought I would fix this much more fast than what it took to me, so I was thinking on sending the report to notify you too... sorry, I will try to do it better next time and write an initial report and another when I find the problem and possible solutions | 05:07 |
| carlos | SteveA: in our database | 05:07 |
| SteveA | ok, so you did the export | 05:07 |
| carlos | I asked an UPDATE command on production | 05:08 |
| SteveA | and then put a date in the database | 05:08 |
| SteveA | but you put the wrong date in? | 05:08 |
| carlos | yeah | 05:08 |
| carlos | I do several exports | 05:08 |
| carlos | one per day | 05:08 |
| carlos | and Martin decides which one is the final one | 05:08 |
| SteveA | I see | 05:09 |
| carlos | he tells me what he used and I put the right timestamp in our database | 05:09 |
| SteveA | how can we avoid this problem in the future? | 05:09 |
| carlos | but seems like I forgot to take into account the mirror delay that we have | 05:09 |
| carlos | moving language pack exports to production and figure a way to handle all those timestamps automatically | 05:10 |
| carlos | I already did some steps in that direction | 05:10 |
| carlos | before moving to carbon to generate language packs | 05:10 |
| carlos | I improved a lot language pack exports | 05:10 |
| carlos | so it takes now between 1 and 2 hours less per distrorelease | 05:11 |
| carlos | without locking the database so much or killing the server with a high load as we were doing in asuka | 05:12 |
| carlos | I changed a couple of queries, the new ones do the same but eating less resources (less joins or rows fetching) | 05:12 |
| SteveA | so, here is an idea | 05:13 |
| SteveA | I don't know if it is practical | 05:13 |
| SteveA | when you do an export, give it a unique ID, maybe by putting a timestamp in a .txt file in the export | 05:14 |
| SteveA | and record that in the database | 05:14 |
| SteveA | so, there is an automatic correspondence between the data exported, and the state in the database | 05:14 |
| SteveA | so, no manual step, except perhaps saying in the database which is actually used | 05:14 |
| SteveA | does that make any sense? | 05:15 |
| carlos | well, that's actually what we do atm or the infrastructure we have was thought that way | 05:17 |
| carlos | but the language packs use a read only database so we are not able to do that | 05:17 |
| carlos | and also, as we do daily lang packs exports, I still need to know which one will be used as the final one | 05:18 |
| carlos | and that still depend on Martin | 05:18 |
| carlos | but, yes, the idea is more or less that | 05:18 |
| carlos | atm, the tarball has a file with the timestamp when it was generated | 05:19 |
| carlos | but it's not completely reliable because it depends on the db mirroring | 05:19 |
| carlos | if one day it's not done, the timestamp would have the date for one day but using a database that is two days older than production | 05:20 |
| SteveA | when you say "timestamp" | 05:26 |
| SteveA | do you mean the time when the files were created | 05:26 |
| SteveA | or the time that is written as text into some file? | 05:27 |
| carlos | when the language pack was generated | 05:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!