=== 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
SteveAso, I have a call with mark in 1.5 hrs04:04
SteveAand I wanted to catch up with you on how 1.0 stuff is going, and any other issues that are around currently04:04
carlosOk, they didn't changed too much since last time we talked04:05
carlosDanilo told me that firefox seems to be done04:05
carlosbut he suggested a new way to handle file imports04:05
carlosto help with OO.org native imports04:05
carlosthat get a single file as input and produces more than one template04:06
SteveAdoes firefox done mean the code is done, with tests?04:06
SteveAthe code is in RF?04:06
carlosso we are able to have 1 file as input and n potemplate or pofile as output04:06
SteveAthe code is committed to danilo's branch?04:06
carlosdone means he's in testing stage04:06
SteveAso, not in RF04:07
carlosnot yet04:07
SteveAbut working prototype, pre review, on danilo's branch04:07
carlosI'm not quite sure whether his suggestion will require changes for firefox, we will have a meeting about it today04:07
carlosI think so04:07
SteveAa single file as input...04:07
SteveAwhat single file would that be?04:08
SteveAI'm trying to understand what you're describing04:08
carlosOpenOffice has all translations inside a single file per language04:08
carlosfor documentation, oo-writer, etc04:08
SteveAso, I can see why we'd want to split that up04:09
SteveAis it obvious how to do that?04:09
carlosbut Rosetta will not represent that as a single template because the amount of messages is huge04:09
carlosyeah, based on top directories where the sources are stored04:09
carloswe have such information inside the file we get04:09
carlosand it's more or less the same split we currently do with the .po bridge we use atm04:09
SteveAand, how does that help FF?04:10
carlosWell, 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 uploads04:10
carlosI don't know exactly how would that affect FF04:11
carlosthe 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
carlosabout TranslationReview and the view restructuration that we talked about04:13
carlosI will have the meeting with danilo today04:14
SteveAso, you'll have an opinion about this tomorrow04:14
carlosas you suggested04:14
carlosyeah, I think so04:14
carlosafter that, I will try to have a preimplementation call tomorrow to start with this as soon as possible04:15
SteveAwhat was the TranslationReview and the view restructuring?04:16
SteveAI don't remember it, bassed on those words along04:16
carlosTranslationReview is the UI that will allow our users to review translations much more easy, it's a 1.0 goal04:16
SteveAbut, what was the view restructuring for it?04:17
carlosview restructuring is a request I got from kiko and that I see as a good thing to do to finish TranslationReview implementation04:17
carlosthat improves the way the views that use the translation form work and reuse code04:17
carlosbecause we have a couple of hacks to reuse POMsgSetView from POFileTranslateView04:18
carlosthat 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 view04:19
carlosbut 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 context04:20
carlosanyway, this is not the final decision, it depends on what I agree with danilo and the reviewer from the preimplementation call04:20
SteveAok.  so, you're starting work on TranslationReview now?04:22
carlosthat task is actually blocked on this04:23
carlosbefore being blocked04:23
carlosI already did most of the UI changes04:23
SteveAyou're saying that TranslationReview is blocked on the view code refactoring?04:24
carlosand part of the view changes, that was the point when I was blocked looking on fixing the views04:24
carlosI could finish TranslationReview spec04:24
carlosbut that would require some hacks04:25
carlosthat I would prefer to avoid and I think could be avoided with the restructuration04:25
carlosok, thanks04:26
carlosyou know, my spanglish...04:26
carlosabout Edgy translations, we already imported most of the .pot files and I think we already fixed the translation domain changes since dapper release04:27
carlosthis is not an official 1.0 goal, but it's an Edgy one04:28
carlosI sent an email last week about translations for documentation that are not part of language packs04:28
carloswould be really good if Mark answers that email04:28
carlosI sent it to launchpad@lists.canonical.com with the subject: "What to do with non language pack translations"04:29
carlosand that will help us to kill what we still have pending in the import queue (atm, 4800 entries)04:31
carloswe 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 wasted04:32
SteveAwhat are the translation domain changes?04:34
carlossome products use their version number as part of the translation domain so with a new release, it changes04:35
carlosand we need to detect those changes and apply them so language packs have the right info04:36
carlosfor instance04:36
carlosfor dapper, evolution used evolution-2.16 as the translation domain, with Edgy, it changed to 2.1804:36
carlosI mean to evolution-2.1804:36
carlosif we don't do that change, the application will be untranslated because it will not find the translations04:37
carlosDo you want to talk about other things that I was working on? or just the ones related with Edgy and 1.0 ?04:40
SteveAfirst, can we just summarize the conversation so far?04:41
carlos- Firefox is in testing phase. Pending to see of the 1 file to n potemplates/pofiles mapping affects it04: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 imported04:44
carlosI think that's all04:45
SteveAthanks, I like the way you produced a clear summary04:46
SteveAit helps me a lot04:46
carlosyou are welcome04:47
SteveAwhat are the other non-1.0 things?04:47
carloswell, there were some bugs fixes and user support requests that I don't think we need to talk about04:47
carlosbut, I detected a problem with Dapper language packs04:47
carloswe had a 'hole' of translations04:47
carlosthat were not in the initial language packs and due a wrong timestamp are not part of the language packs updates04:48
carlosI think I detected all those files and agreed with Martin Pitt in a way to solve the situation04:48
carlosI'm going to prepare a brief summary to the mailing list04:49
carlosthe 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 released04:50
carlosand that prevented language packs updates to include the updates done in those dates04:50
carlosthat's mainly koffice translations04:51
SteveAso koffice translations (mainly) missing in dapper langpacks04:54
SteveAbecause of a timestamp problem04:54
SteveAmeaning that there were translations made after the initial langpack was shipped with dapper04:54
SteveAthat were missed out of the updates04:54
SteveAis that right?04:54
carlosbecause those translations came from upstream04:55
carlosand no other ubuntu translator touched those pofiles04:55
carlosthe plan to fix this is to 'touch' a translation in those pofiles to force a new export04:55
SteveAso, the fix is to "touch" a translation in each pofile with a hole04:56
SteveAforce a new export04:56
SteveAand these will be in the next langpack update04:56
SteveAhow did you find out about the problem?04:56
carlosyeah, that's the solution04:57
carlosbecause from time to time, a KUbuntu user complained to someone that then complained to me04:57
carlosuntil a couple of weeks ago04:57
carloswhen a KDE developer that tracks our KDE translations04:58
carloswarn me about the problem and help me to debug it04:58
carlosprevious complains came from GNOME users that were not able to help me with that04:58
carlosand 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 problem04:59
carlosI'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 tracking05:00
SteveAdo you know how the timestamp problem occurred in the first place?05:04
SteveAalso, when you have a problem like this, please let me know that it has occurred05:04
SteveAit's the kind of thing someone may ask me about, and I'd feel stupid for not knowing05:04
carloswell, it was a mix of communication problem between Martin pitt and me and the fact that we use a mirror to export language packs05:05
carlosso I put there the wrong date05:06
carlos(we still do this manually once the final release is done)05:06
SteveAwhere did you put the wrong date?05:06
carlosI 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 solutions05:07
carlosSteveA: in our database05:07
SteveAok, so you did the export05:07
carlosI asked an UPDATE command on production05:08
SteveAand then put a date in the database05:08
SteveAbut you put the wrong date in?05:08
carlosI do several exports05:08
carlosone per day05:08
carlosand Martin decides which one is the final one05:08
SteveAI see05:09
carloshe tells me what he used and I put the right timestamp in our database05:09
SteveAhow can we avoid this problem in the future?05:09
carlosbut seems like I forgot to take into account the mirror delay that we have05:09
carlosmoving language pack exports to production and figure a way to handle all those timestamps automatically05:10
carlosI already did some steps in that direction05:10
carlosbefore moving to carbon to generate language packs05:10
carlosI improved a lot language pack exports05:10
carlosso it takes now between 1 and  2 hours less per distrorelease05:11
carloswithout locking the database so much or killing the server with a high load as we were doing in asuka05:12
carlosI changed a couple of queries, the new ones do the same but eating less resources (less joins or rows fetching)05:12
SteveAso, here is an idea05:13
SteveAI don't know if it is practical05:13
SteveAwhen you do an export, give it a unique ID, maybe by putting a timestamp in a .txt file in the export05:14
SteveAand record that in the database05:14
SteveAso, there is an automatic correspondence between the data exported, and the state in the database05:14
SteveAso, no manual step, except perhaps saying in the database which is actually used05:14
SteveAdoes that make any sense?05:15
carloswell, that's actually what we do atm or the infrastructure we have was thought that way05:17
carlosbut the language packs use a read only database so we are not able to do that05:17
carlosand also, as we do daily lang packs exports, I still need to know which one will be used as the final one05:18
carlosand that still depend on Martin05:18
carlosbut, yes, the idea is more or less that05:18
carlosatm, the tarball has a file with the timestamp when it was generated05:19
carlosbut it's not completely reliable because it depends on the db mirroring 05:19
carlosif 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 production05:20
SteveAwhen you say "timestamp"05:26
SteveAdo you mean the time when the files were created05:26
SteveAor the time that is written as text into some file?05:27
carloswhen the language pack was generated05:28

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!