Difference between revisions of "Extensions/website/Minutes/2007-10/2007-11-08-IRCLogs"

Latest revision as of 00:29, 5 March 2010

(11:05:32) bettina-h: I am starting with the actionitems: 2_2007-10-04: Clarify infrastructure for localization of static content with Thorste
(11:05:47) bettina-h: JSC / TBO?
(11:05:53) mdamboldt: So today we have two guest. They are Rafaella and Pavel.
(11:06:17) bosi: 2_2007-10-04: still in progress
(11:06:23) jsc: nothing from me on both AI's because i am busy with other stuff
(11:06:35) bettina-h: 3_2007-10-04: Propose workflow for localization of static content: JSC?
(11:07:05) jsc: no news, depends on the last AI
(11:07:10) bettina-h: 1_2007-10-11: Set up mail address for feedback reporting. Laurent?
(11:07:42) mdamboldt: jsc: We should take the opertunity today to discuss more details about the localization, thats why Rafaella and Pavel joined today and we shifted the meeting by one hour to enable them to participate.
(11:07:43) lgodard: will see
bettina-h bosi 
(11:07:55) lgodard: this afternoon with stx12 and bosi
(11:07:56) buchanae [n=buchanae@ash.osuosl.org] est entré dans le salon
(11:08:15) lgodard: mdamboldt: i totally agree, welcome to them
(11:08:38) jsc: well, that make sense but i can't add something to the AI's ;-)
(11:08:40) rafaella: thanks, mdamboldt lgodard
(11:08:43) lgodard: stx12: bosi is not available before 16
(11:08:56) bettina-h: So to quick summarize, the status of the action items, except of the last one, will be taken over, MD?
(11:09:33) bosi: 1_2007-10-18 is done.
(11:09:40) mdamboldt: bettina-h: No update on my AI's, still only the draft available, nothing has been placed on the site yet.
(11:09:46) bettina-h: So that we can start with the discussion.
(11:09:56) bosi: I just placed it on teh site :-)
(11:10:04) mdamboldt: bosI: ??? Oh, didn't saw that.
(11:10:08) lgodard: bosi: what about translation ?
(11:10:14) lgodard: bosi: is it planned ?
(11:10:24) bosi: lgodard, in progress .... still
(11:11:01) bettina-h: Ok, let's start with discussing l10n.
(11:11:03) lgodard: bosi: did you work with andreas ?
(11:11:09) SunNF: lets focus on the l10n workflow, as pavel and rafaella are on board. As I suggested last week, we should align the translation workflow with those of the OOo product itself.
(11:11:10) lgodard: bettina-h: ok
(11:11:21) lgodard: SunNF: which part ?
(11:11:36) lgodard: SunNF: do you confirm we are speaking of the static part ?
(11:11:41) lgodard: of the website ?
(11:11:59) SunNF: lgodard: yes
(11:12:24) lgodard: SunNF: ok
(11:12:41) lgodard: what is the structure of linguistic used by drupal ?
(11:12:43) lgodard: po files ?
(11:12:59) jsc: Part I: static text on the website
(11:13:01) jsc: we use the Drupal localization framework to do the work -> output po files
(11:13:03) jsc: question: how can we use the existing process to translate them
(11:13:42) rafaella: jsc, you mean the current localization process we use for OOo GUI and Help?
(11:13:58) jsc: 1. extract them manually and feed them in the database -> translate -> feed back in the system manually
(11:14:00) jsc: shouldn't be necessary to often, right
(11:14:17) jsc: rafaella: yes, if possible
(11:15:28) jsc: any opinions, i haven't enough detail knowledge about the current process
(11:15:44) rafaella: I am not familiar with the drupal localization framework, can you say more about this?
(11:16:41) bosi: is the information enough, that I can get .po files for translateable string out and in of drupal
(11:16:46) jsc: i think it is probably not necessary. More interesting is if we can use the po files in the current process
(11:16:46) bosi: ?
(11:18:13) rafaella: jsc, you are saying that you extract the files manually. Out of the OOo CVS?
(11:19:19) jsc: no, no cvs is involded here. I mean we extract the po files from the Drupal system (from repository) and put them manually in the database
(11:19:48) rafaella: jsc, you mean into the internal database?
(11:20:06) jsc: yes, if possbile
(11:20:50) jsc: which database is the community using?
(11:22:40) rafaella: Community cannot use the internal datase .... the process thorugh the internal database is done by Sun
(11:23:05) paveljanik: if the export from extensions is a PO file or a set of PO files, we can generate POT files from them and use the current methodology to translate files - just in a new project.
(11:23:06) lgodard: we have tools to extract sdf
(11:23:24) lgodard: paveljanik: i agree
(11:23:37) rafaella: yes, and Community teams use sdf to localize
(11:23:39) paveljanik: it would be nice if extensions site simply provides a set of POT files (both UI and extensions strings)
(11:24:05) lgodard: jsc: is there a way to automate the import/export to drupal
(11:24:09) jsc: ok, i understand. Well they should be work. But iam not sure if it's worth the effort with a new project (at least for the static text of the website)
(11:24:25) lgodard: paveljanik: extensions string is a different problem
(11:24:26) jsc: they -> that
(11:24:50) paveljanik: lgodard: ok, but extensions should have one, defined interface to translators - not more.
(11:24:51) lgodard: jsc: what do you mean ?
(11:25:12) jsc: lgodard: we don't need any automatism for the static text. I don't expect frequent changes here
(11:25:27) paveljanik: jsc: "new project" is a new project for translators - you can understand it as a different group of PO files.
(11:25:40) lgodard: jsc: frequuent changes for one languages, but multiply it by 80 (Native lang)
(11:26:21) jsc: lgoard: but not for the static text
(11:26:28) rafaella: jsc, and even if the changes are minimal the efforts to update the pages multiplied by 80 are hudge...
(11:26:29) kazalubak [n=chatzill@83.230.2.10] est entré dans le salon
(11:26:30) lgodard: jsc: why ?
(11:27:30) jsc: paveljanik: ok i understand
(11:27:31) jsc: lgodrad: i think we don't plan to change the static text on the website every week or month, right?
(11:27:57) jsc: please don't mix it with the dynamic text for extensions
(11:28:14) lgodard: jsc: i do not mix
(11:28:37) lgodard: jsc: do you expect that all the 80 languages will provide their translations at once ?
(11:28:39) bosi: rafaella, is there a page where the process between the files is explained? so If i deliver a pot file, what will happen to it, and what do i get back?
(11:29:42) jsc: lgoard: no, but i think that is a minor issue and we can do it on demand when a new language is ready
(11:29:57) rafaella: bosi, you get an SDF file back
(11:30:03) paveljanik: bosi: POT is a template. Translator will use the template to update its local translation repository (keep translated strings, ...) and will have PO files on his machine. He will provide you PO file.
(11:30:13) lgodard: jsc: no, as some languages will request minor typo changes everytime
(11:30:27) rafaella: and sdf can be conbverted to .po
(11:30:44) paveljanik: but in this case, where input is PO/POT, we do not need SDF at all.
(11:30:56) rafaella: paveljanik, right
(11:30:58) lgodard: paveljanik: yes
(11:30:59) jsc: paveljanik: that sound good. So we can simply create a new project for our po files for the static text
(11:31:37) paveljanik: jsc: yes. And *if* you have some texts for extensions, just do the same please.
(11:31:40) paveljanik: in the same form.
(11:31:45) bosi: ok, the general translation for statis
(11:31:53) lgodard: paveljanik: i'm not sure
(11:31:55) bosi: <delete> ;-)
(11:32:19) lgodard: paveljanik: what we call dynamic text, extension description on the site, will be quite huge
(11:32:46) paveljanik: and thus we will translate it differently?
(11:32:47) paveljanik: nono
(11:32:48) rafaella: lgodard, how huge?
(11:32:59) paveljanik: is it larger than helpcontent2?
(11:32:59) lgodard: paveljanik: are translators ready to *systematically* translate them or do we involve volunbteers and then, there's only a review involved
(11:33:00) paveljanik: ;-)
(11:33:12) paveljanik: lgodard: how is this connected?
(11:34:06) lgodard: paveljanik: i only wonder if OOo translators will be able to react on all extensions input
(11:34:08) jsc: mmh, well for extensions we have the problem that we have two different kind of resources ...
(11:34:10) jsc: 1. text taht is visible on the website
(11:34:11) jsc: 2. resources in the extensions, e.g. string resources for dialogs, help files, ...
(11:34:12) jsc: and we don't have always the sources for the internal resources
(11:34:14) jsc: So should differentiate between these two things
(11:34:37) paveljanik: jsc: do whatever is needed, but for translators, please use only *one* interface.
(11:35:05) lgodard: paveljanik: what about po files but, for a verification phase only
(11:35:11) rafaella: paveljanik, I completely agree
(11:35:21) lgodard: jsc: i agree on points 1 and 2
(11:35:55) jsc: i agree in general as well but it is different than normal resources
(11:36:02) ***jsc ...thinking
(11:36:10) lgodard: for my point of view, http://wiki.services.openoffice.org/wiki/Extensions/website/Translating
(11:36:26) lgodard: any user qhould be able to provide translations
(11:36:40) lgodard: this would ease the work of each native lang
(11:36:57) lgodard: it is easier to check than create the translation
(11:37:22) lgodard: this general approach will use 2 different way for jscpint 1 and 2
(11:37:31) jsc: Drupal offers also a web frontend to do translation. That could be interesting for the dynamic texts for extensions ... But well it would be different
(11:37:47) lgodard: jsc: i agree, we usse drupal
(11:38:04) lgodard: jsc: for point 1
(11:38:21) lgodard: jsc: with someone repsonsible in checking that the translation is ok
(11:38:38) bosi: I would take a look, how big the efford would be to extract the dynamic part into po files - to have in generakl just one interface for translation.
(11:38:45) lgodard: jsc: i think we should avoid restricting too much the ability to translate
(11:39:17) lgodard: jsc: and everyone should be able to submit a translation on a specific extension description
(11:39:21) rafaella: lgodard, you need to get the buy-in from the native language Community leads....
(11:39:43) lgodard: rafaella: buy_in ?
(11:39:55) rafaella: lgodard, commitment, agreement
(11:40:00) jsc: bosi: that is a good idea...
(11:40:02) jsc: but open than still the question how internal resources could be translated?
(11:40:03) jsc: My suggestion is simple: if extensions developers want to use this feature they should use our cvs repository.
(11:40:24) jsc: i mean internal of extensions like help files etc.
(11:40:28) rafaella: jsc, which internal resources?
(11:40:30) lgodard: rafaella: this has already been announced , see the page i gave
(11:40:43) bosi: jsc, you mean for the extension itself, not something on the websit?
(11:40:48) lgodard: jsc: no, for internal ressources
(11:41:01) lgodard: bosi: that is point 2
(11:41:20) lgodard: for point 2, agin, we should involve more the users and community at large
(11:41:41) lgodard: remember the discussion on the translation framework we had several month ago
(11:42:36) paveljanik: should the translation by everyone be done on extension site or on Pootle?
(11:42:36) jsc: bosi: correct
(11:42:37) lgodard: some nice that allow any user to edit the strings, translate, dynamically verify, and submit its translation (po file). then only a verification is required, and the extension owner can then add
(11:43:07) lgodard: paveljanik: i would say on extension site, like a "translate me" button
(11:43:18) lgodard: near a description that need to be translated
(11:44:18) bosi: lgodard, that workflow is open to leaving out some strings - that's why mozilla community developed their own module iin drupal for translation.
(11:44:21) lgodard: rafaella: http://wiki.services.openoffice.org/wiki/Extensions/website/Translating/NL_Representative this has been filled after a call on NL list
(11:44:26) paveljanik: In my opinion, extensions site should provide strings (UI, static texts, extensions descriptions, ...) in POT format to translators and only they should translate strings. Recomendation of translation is a different beast.
(11:44:38) jsc: paveljanik: i think that is still the question. But we would like to reuse the existing process
(11:45:15) paveljanik: and I was talking about *every* string, not *some* strings.
(11:45:27) jsc: paveljanik: i would agree and we should think i this direction. However we can achieve it ...
(11:45:43) paveljanik: for UI coming from drupal, you already have PO.
(11:46:06) paveljanik: for extensions, the workflow should be defined together with processes, namingscheme etc.
(11:46:14) paveljanik: But you know this more than me ;-)
(11:46:25) lgodard: paveljanik: i think, with more and more extension comming, that translation of description of *all* extensions will not be that easy
(11:46:43) jsc: paveljanik: yes i agree and we will think in this direction
(11:47:07) paveljanik: lgodard: agreed, thus all strings have to be in one place and the translation recommendation should be handled by pootle
(11:47:44) lgodard: paveljanik: do you agree that it is better to submit requests on checking an existing translation instead of doing the translation ourselves
(11:48:39) lgodard: paveljanik: can be in po format though
(11:49:04) rafaella: lgodard, it's really difficult to agree for 80 languages
(11:49:22) lgodard: rafaella: why ?
(11:49:35) jsc: lgodard: it's always the same and the work have to be done anyway. Let us focus on resuing the existing process. We can put in front of it whatever we want and ...
(11:49:36) rafaella: lgodard, the level of expertise of one team may be very different from another
(11:49:37) jsc: whatever you implement ;-)
(11:50:16) rafaella: for one language it can be good enough to check a translation or take it as it is and for another you know that it is better to translate it from scratch
(11:50:30) lgodard: jsc: i already implemented some uno services months ago dealing with this approach. has been rejected because of dialogs and .properties files
(11:50:44) lgodard: jsc: and now, what
(11:51:10) lgodard: rafaella: depends on the native lang volunteer, no ?
(11:51:15) jsc: lgodard: i don't understand you
(11:51:57) rafaella: I think that we should define here NOT the task a translator should perform but the interface to use
(11:52:14) SunNF: rafaella: +1
(11:52:23) lgodard: jsc: look at dev@extensions archives then ...
(11:52:33) lgodard: jsc: btw, lets discuss this later, please
(11:52:36) rafaella: the process to get the files to translate and the the process how to merge them back
(11:53:02) SunNF: As I understood, there was already agreement on the interface, right? Using po/pot for each and every string as the one and only format for tranlation handover on a regular base. did i get that right?
(11:53:29) paveljanik: SunNF: yes.
(11:53:38) jsc: yes, i think so
(11:53:44) paveljanik: input to translators in POT, output in translated PO.
(11:53:57) paveljanik: input can be translated PO as well.
(11:54:09) lgodard: ok, but who translate ?
(11:54:14) rafaella: for all extensions parts
(11:54:14) paveljanik: or semi-translated (for recommended translations)...
(11:54:29) SunNF: ... as a seperate project from the tranlatorrs perspective ...
(11:54:31) lgodard: only the ooo l10n team, or do we open to a larger potential ?
(11:54:51) jsc: let me ask one question. The new dialog resource format is similar ot Java property files. Can we translate or convert them in pot files as well
(11:54:51) SunNF: redirect the larger potential to the ooo l10n team?!
(11:54:54) paveljanik: lgodard: this is also legal question...
(11:55:01) lgodard: translating an extension should not require any knowledge
(11:55:36) rafaella: lgodard, I am not sure ... at least you need to have language knowledge
(11:55:41) lgodard: jsc: i think it is doable, buit best would be to natively support po files
(11:56:05) lgodard: rafaella: of course, but that is that only knowledge that is required
(11:56:06) bosi: paveljanik, how is the translated file delivered after translation? via cvs, mail ...?
(11:56:21) lgodard: rafaella: no technical skills such as editing a file, aso
(11:56:45) lgodard: paveljanik: that is why NL representative should validate the translations
(11:57:25) rafaella: lgodard, do you want extensions to be translated properly?
(11:57:35) paveljanik: bosi: right now, OOo doesn't provide PO, but en-US.sdf. This file is converted into POT and translators use it as they are used to. The output from the is a set of PO files (in CVS, in Pootle). The output to OOo is created using the original en-US.sdf file and PO files.
(11:57:42) paveljanik: and is again SDF file.
(11:57:44) lgodard: rafaella: sure, but, translation be transted
(11:57:53) lgodard: rafaella: translated at first
(11:57:54) paveljanik: This is how it works for OOo (UI and help).
(11:58:55) lgodard: SunNF: redirecting to l10n won't work and we will loose contributors (yes for only one extension they are interrested in, but better tha nothing)
(11:59:13) rafaella: lgodard, but still there are a couple of things that you need to know in order to translate....
(11:59:47) lgodard: rafaella: not for extensions and for having a first translated description. 
(12:00:01) SunNF: lgodard: I think we should try to get extensions developed on OOo. If we can do so, the common OOo l10n process will fit.
(12:00:13) lgodard: rafaella: the real problem here is the growing number of extensions x 80 languages
(12:00:29) paveljanik: 80 only? ;-)
(12:00:33) SunNF: lgodard: if extensions are developed elsewere, we should leave it up to the developer to get the stuff translated
(12:00:34) lgodard: if we do not open, we will end with a lot of untranslated extensions that couls have been 
(12:01:00) paveljanik: lgodard: but the process you talk about is orthogonal to the one we are talking about now.
(12:01:01) lgodard: SunNF: do not agree. extension project should give a framework 
(12:01:08) rafaella: lgodard, I don't think this is an issue if we set up the process properly
(12:01:10) paveljanik: both can coexist.
(12:01:23) SunNF: lgodard: otherwise, we have to develop a deeper understanding about license issues, legal stuff, ... and I think we are not able to do this here
(12:01:46) lgodard: paveljanik: yes can coexist, but i do ot want that it is restricted to l10n only team
(12:02:02) paveljanik: lgodard: why it should be restricted?
(12:02:16) lgodard: paveljanik: yes why ....
(12:02:19) paveljanik: We can have what you told us before on Pootle, automaticly. But for languages that *want* to have this.
(12:02:49) paveljanik: but this is really separate process.
(12:02:57) lgodard: paveljanik: ok
(12:03:55) lgodard: SunNF: it will be the owner at end that decides to include the translation or not. at creation on the website, a "translatable" metadat ccould be set
(12:05:30) lgodard: lets conclude ?
(12:05:41) lgodard: our support format for translation is po/pot
(12:06:32) lgodard: evry resources , web static/dynamic and extensions have too be exportable to this file format
(12:06:53) lgodard: what else ?
(12:07:39) paveljanik: Extensions site will provide all translatable content in one PO/POT file set.
(12:07:45) paveljanik: tar ball or whatever.
(12:07:59) paveljanik: Not three or more separate translatable sets.
(12:08:04) paveljanik: Just one "project"
(12:08:07) jsc: can we all agree to go in direction of reusing the existing process?
(12:08:08) jsc: We focus on a process how we can integrate the po files from Drupal in the existing process.
(12:08:09) jsc: lgodard: we can of course think about a new frontend where extension developers can request help for translation. However it should work in detail. In the end this frontend would deliver po files in the existing process. But for that more details have to be defined
(12:08:11) jsc: paveljanik: yes
(12:08:21) lgodard: paveljanik: for each extension ?
(12:08:45) paveljanik: lgodard: imagine a tree of translators:
(12:08:47) paveljanik: OpenOffice.org
(12:08:51) paveljanik: Mozilla
(12:08:52) paveljanik: KDE
(12:09:00) paveljanik: under OpenOffice.org, they now have
(12:09:01) paveljanik: binfilter
(12:09:03) paveljanik: avmedia
(12:09:05) lgodard: jsc: this translation should be done online for the website and from within ooo for the extension
(12:09:05) paveljanik: helpcontent2
(12:09:31) paveljanik: We should provide them one directory and all PO files there - under one directory/project - all downloadable from one place.
(12:09:41) paveljanik: maybe I do not express this too clearly ;-)
(12:09:50) paveljanik: to negate:
(12:10:27) paveljanik: I do not want translators to download OpenOffice.org-SRC680_m237-POT.tar.gz from one site for OOo and its UI and helpcontent and then three or four other files for:
(12:10:31) paveljanik: - extensions site UI
(12:10:37) paveljanik: - extensions descriptio
(12:10:41) paveljanik: - extensions help
(12:10:50) paveljanik: - extensions names
(12:10:51) paveljanik: etc.
(12:11:03) jsc: paveljanik: of course i understand it make sense
(12:11:20) paveljanik: then the question is on you to define proper structure, naming scheme.
(12:11:23) lgodard: jsc: then we need a common translation framework for extensions
(12:13:14) lgodard: paveljanik: do you really want that all the extensions are parsed, gathered in one single set and translated bye OOo team ?
(12:13:31) lgodard: paveljanik: ok ok, i stop
(12:13:35) paveljanik: lgodard: yes, definitely!
(12:13:39) lgodard: paveljanik: i already expressed my opinion
(12:14:19) paveljanik: using their translation cache shared with the project, using their resources and with the possibility to accept recommendation to translation from others.
(12:14:27) jsc: lgodard: i think we have it if ext developers would use our repository....
(12:14:29) jsc: - we have property files for dialogs
(12:14:30) jsc: - we will have help files
(12:14:32) jsc: - we have extension descriptions, names
(12:14:33) jsc: - localized config items
(12:14:35) jsc: - maybe be more
(12:14:51) lgodard: jsc: which repository ?
(12:14:57) lgodard: cvs ?
(12:16:01) jsc: lgodard: yes
(12:16:03) jsc: But i know that this is not a solution for everyone and we should think about a further way ...
(12:16:23) lgodard: jsc: only a minority of extension dev. will accept and and even know hos to use CVS
(12:16:48) lgodard: jsc: moreove, what about licences aso.
(12:17:05) jsc: that is the reason why i have suggested an additional frontend....
(12:17:59) lgodard: i think the cvs should be kept for validated and valuable popular extensions. By default consider them as wild
(12:18:15) jsc: we can't solve it today, we have 12:15 and i have to leave soon ....
(12:18:27) lgodard: jsc: right
(12:19:22) jsc: thanks to Pavel and Rafaella to share their opinion with us and i think we know where have to move forward ...
(12:20:00) rafaella: jsc, you're welcome
(12:20:07) jsc: anything from somebody else?
(12:20:28) lgodard: i have 2 questions
(12:20:29) paveljanik: jsc: thanks for inviting us.
(12:20:43) lgodard: 1. where are the sources of the site
(12:21:18) lgodard: 2. can we move the meeting on afternoon 14 next time so that all time zone (esp. american) can attend ?
(12:21:49) lgodard: 2. is directly from Alexandro question on the mailing list
(12:21:53) bosi: lgodard, 1. http://wiki.services.openoffice.org/wiki/Extensions/website/setup
(12:22:02) mdamboldt: lgodard: Not sure what calendars of other say, but I will check.
(12:22:16) jsc: same for me
(12:23:02) lgodard: bosi: thx
(12:23:22) mdamboldt: lgodard: By afternoon 14 you mean 14:00 CET ?
(12:23:27) lgodard: i think 14 is good , morning in america and evening in asia
(12:23:29) jsc: i have to leave now, bye and thanks
(12:23:34) jsc est désormais connu sous le nom de jsc_away
(12:23:52) mdamboldt: lgodard: Morning in the US only on the east coast.
(12:24:10) lgodard: yes, CET
(12:24:18) lgodard: and east cost, yes
(12:24:42) lgodard: i propose to ask on the mailing list ?
(12:24:59) lgodard: do you agree ?
(12:26:09) mdamboldt: lgodard: Let me first check my own schedule and those of others, too. There are alreadya couple of people where the current slots fits.
(12:27:05) mdamboldt: lgodard: I agree that moving it would make sense, but we should not open it like "whish you what ever you like".
(12:27:35) mdamboldt: I have to leave now....
(12:27:39) bettina-h: bye
(12:28:08) rafaella: bye