Extensions/website/Minutes/2008-04/2008-04-24-IRCLogs

(10:03:09) lgodard: Hi all
(10:03:23) lgodard: sorry for being "late"
(10:03:37) lgodard: so lets start ?
(10:03:52) lgodard: first time as Minute taker for me, so please forgive me in advance ;)
(10:04:16) lgodard: 5 points to check and then the round table
(10:04:28) lgodard: ready all ?
(10:04:34) bosi: yes
(10:04:36) lgodard: 2_2007-10-04: Provide infrastructure for localization of static content (TBO)
(10:05:10) bosi: currently stalled; I will start next time to ask for other translations in nl group.
(10:05:47) bosi: next topic ?
(10:05:52) lgodard: ok
(10:06:00) lgodard: 3_2007-10-04: Propose workflow for localization of static content (JSC)
(10:06:04) lgodard: depending on previous
(10:06:12) lgodard: next
(10:06:15) lgodard: 1_2008_02_28: Provide a draft regarding enhancement of the extension site to provide also single templates and cliparts (BH)
(10:06:41) bettina-h: I have to hand over to Nils. Nils, could yoou please jump in?
(10:07:21) SunNF: i would say in progress. we will provide what we have on the mailing list, later on.
(10:07:53) lgodard: SunNF: AI for next meeting ?
(10:07:59) SunNF: yes
(10:08:23) lgodard: "initiaite discussion on mailing list regarding single templates and cliparts extensions"
(10:08:46) SunNF: fine with that on for now.
(10:08:53) lgodard: ok
(10:08:57) lgodard: 2008_04_10: Ask Stella about putting the new branding from www.openoffice.org onto the extension site (MD)
(10:09:01) mdamboldt: Unfortunatly I missed to take care of this AI and just stumbled over it this morning again. (Sorry!)
(10:09:01) mdamboldt: Till now I didn't reach Stella today,but I will follow up on this asap with here.
(10:09:26) lgodard: mdamboldt: ok, In Progress
(10:09:34) lgodard: ok, AI for netx meeting
(10:09:57) lgodard: next
(10:10:00) lgodard: 2008_04_10 :  how process is to translate an extension itself, contcat jsc (lgodard)
(10:10:13) lgodard: same answer as mdamboldt previous one ;)
(10:10:39) lgodard: jsc: do you have some points ? maybe more to be discussed on mailing list ?
(10:11:01) jsc: yes, i can give some comments ...
(10:11:07) lgodard: jsc: great
(10:11:34) jsc: if somebody wants to translate an extension in the normal build env it is straight forward.
(10:12:26) jsc: the developer has to take care of some special requirements of the buikld env and thats it. Once the source is in the build env everything shoudl work automatically
(10:13:07) lgodard: what about for "external" extensions ? any convention to follow to ease the process for translation team ?
(10:13:48) jsc: no not so far. We focus only on source in the normal repository
(10:14:17) lgodard: jsc: can we create a link to join this process ? doable ?
(10:15:12) jsc: from my point of view it is not optimal because a lot of extension are not build frequently, especially external ones. It would be nice if we would have some thing independent of the build process.
(10:15:26) lgodard: jsc: remember some king of translation framework for extensions (runtime, developper)
(10:15:29) lgodard: jsc: i agree
(10:17:03) SunNF: didn't we had a meeting with Rafaella and Pavel on this?
(10:17:38) jsc: yes, that is what we do when extensions in the normal build env
(10:17:43) lgodard: SunNF: pavel gave its pov once but i think it was for the website content and not the extensions themselves
(10:18:12) jsc: it's more or less the same after some processing during the build
(10:19:05) lgodard: jsc: do you have the detail of the whole process for 'internal' extensions
(10:19:07) lgodard: ?
(10:19:08) SunNF: my question is: is there realy the need for diferentiation for "externel" extensions? Who raised this issue beside ourselfs?
(10:19:51) lgodard: SunNF: external extensions, we may not have the sources and author may not fit the development process (using cvs aso)
(10:20:15) SunNF: so he should if he likes to participate the l10n process, roght?
(10:20:31) SunNF: isn't that a motivator to join?
(10:21:02) lgodard: SunNF: yes, that is a way
(10:21:09) lgodard: to recruit
(10:21:30) SunNF: I like to ease contribution to the open source part of OOo.
(10:21:39) SunNF: for core and extensions
(10:21:51) lgodard: SunNF: extensions contribution is a first step
(10:22:20) SunNF: agreed
(10:22:24) jsc: SunNF. do we have not open source part of OpenOffice ?
(10:22:33) lgodard: SunNF: but we have to ease the process as we cab't ask volunteers to dive into cvs for soem translation. otherwise we will lost a lot
(10:22:51) lgodard: jsc: :)
(10:23:03) lgodard: jsc: not any more since dev guide ;)
(10:23:04) SunNF: jsc: somehow yes: non opensource extensions within the repository which is within the OOo domain.
(10:23:40) lgodard: SunNF: i don't see them as part of OOo. Just OOo is interrested in listing them
(10:24:49) SunNF: lgodard: As I also don not see them as real part of OOo, I don't like to ease the l10n stuff for them. At the end, they do not contribute code.
(10:24:50) lgodard: so, translation, juergen, can you point us on the process and lets ask for l10n team pow and define a translation framework. is it ok ?
(10:25:16) jsc: created ext with NB are possible to integrate in the build process but there is space for improvements.
(10:25:19) lgodard: SunNF: but, if they bring value for OOo user, that's important
(10:25:47) lgodard: SunNF: and once it becomes free (lets dream) it is more easy
(10:26:12) lgodard: SunNF: but even without that, an extension will be ssen for majhority of users as part of OOo menus
(10:26:34) lgodard: SunNF: but i agree that our translation resources should not be used for such extensions
(10:27:03) jsc: For example property files for dialogs created with the dialog editor. In the build process we can't use them directly have to duplicate the string in new format. Later we generate again property files form the new format. Really strange from my point of view.
(10:27:04) lgodard: SunNF: if we create a translation framework, lets make it free and part of the extension definition process, no ?
(10:27:05) jsc: SunNF: do you mean to simplify stuff like this?
(10:27:19) SunNF: +1 for including the l10n community or their reps to this discussion
(10:27:48) lgodard: jsc: +10 so it is important toi define how a translation is done in extensions
(10:28:25) SunNF: jsc: I think, the easier it is to provide fully localized non os extensions, the lower is the motivation to contribute the code.
(10:29:00) SunNF: So +1 for a easy process and +1 for even a even easier process for os extensions.
(10:29:32) jsc: the biggest problem that i see is that extension even when they are in our repository are independent from the normal office build. But the localization depends somewhat on the release cycles of OO.org right?
(10:30:18) SunNF: jsc: if so, we should solve exactly that issue.
(10:30:48) SunNF: jsc: we shoud work on decoupling the build and release cycles
(10:31:06) SunNF: jsc: and of caus the translation cycles
(10:31:12) jsc: SunNF: i agree we should try to decouple it from the release cycle if possible. At least for extensions
(10:31:41) jsc: SunNF: you can type faster ...
(10:31:47) SunNF: :-)
(10:32:11) lgodard: jsc: one goal is also to unify the way a extensions is translated. an UNO engine could be usable for all kind of extensions
(10:32:23) lgodard: so conclusion ? 
(10:32:33) jsc: lgodard: what do you mean?
(10:33:48) lgodard: jsc: someone developing in java, ooobasic, python, c++ should use the same uno service that takes the "translation file" in the extension and serve it to te calling code
(10:34:08) lgodard: jsc: but this is something different of what we discussed previously
(10:35:12) jsc: well we have several "resource" formats. The property files for dialogs are the same for all languages, xcu files are also the same. Maybe one goal for the future would be to unify the resource formats to only one ....
(10:35:38) lgodard: or to provide a common gate to access them
(10:35:54) lgodard: i think it is much simpler for a first step
(10:36:03) lgodard: but yes
(10:36:44) lgodard: jsc: we also have to see accross teh developpers, so that everybody uses approcimativelly the same things and can help each other
(10:37:41) jsc: i am not sure if i understand you. We put all the different formats during the build in one common format in a db and translate it. Later on we extract teh localized string and put them back in the original format.
(10:38:25) jsc: i don't see the point of or for a UNO engine
(10:38:49) lgodard: jsc: how an extension developper access this resources ? an UNO engine is common to be language independant
(10:39:43) jsc: we have that for the property files. xcu files are handled normally by a framework automatically
(10:40:21) jsc: ... framework or by the service provider interface that has defined the config schema
(10:40:26) lgodard: how are property files red by OOobasic extensions, python extensions, c++ aso
(10:41:16) SunNF: I got lost somehow. What's the outcome of the prev discussion, beside the discussion itself?
(10:41:20) jsc: there is a service availbale ... let me have quick look for the name ...
(10:41:58) lgodard: jsc: ok, then if something exists. lets discuss this later
(10:42:16) jsc: ok not quick because the connection is so slow at the moment. I will provide it later ....
(10:43:28) lgodard: SunNF: there is 2 levels. the extension producers that need a defined methodology of translating an extension (and tools for manipulating); the second level is the translation process and release cycle itself and l10n team implication
(10:43:35) lgodard: lgodard: am i wrong ?
(10:43:59) lgodard: jsc: no problem, lets discuss this on dev@extensions ?
(10:44:07) jsc: the outcome is that we don't use some new UNO "engine" to allow access on localized strings. But we need simplification in the build process to reuse the existing formats.
(10:44:25) SunNF: lgodard: OK, so I think Juergen and I should come up with some ideas how to do this decoupling stuff and find out the opinion of other stakeholders, such as release management and the l10n team.
(10:44:48) lgodard: SunNF: ok AI ? due date ?
(10:44:49) jsc: ... without a redundant intermediate format.
(10:45:12) SunNF: jsc: will be our first shared AI ever :-)
(10:45:17) lgodard: jsc: well, an open format for interoperaability of tools ;)
(10:46:12) SunNF: lgodard: Yes, AI pleas. Due End of Mai?
(10:46:22) jsc: SunNF: really? Fine, i am sure you will invite me to discuss it later on, right?
(10:46:34) SunNF: jsc: Yes
(10:46:40) lgodard: jsc: a small AI for you, post on dev@extensions the UNO service for translation and discuss it to see if fits all the needs ?
(10:46:40) bosi_ [n=bosi@nat/sun/x-df4c2ffa2e93a8ba] est entré dans le salon
(10:46:57) lgodard: SunNF: ok, end of may
(10:47:02) jsc: lgodard: i will do it
(10:47:08) lgodard: jsc: ok, thx
(10:47:10) lgodard: so
(10:47:42) lgodard: round table ?
(10:47:46) mdamboldt: Update regarding my AI 2008_04_10:
(10:47:46) mdamboldt: I just talked to Stella. She already stumbled over the different between the Extension site banner and the new OOo site banner, too. She really likes to exchange that as soon as time allows here to work on additional tasks like this. Right now she is blocked with other more important items. A first estimation is that she might be able to start working on this in the first week of May 2008 (cw19).
(10:48:28) lgodard: ok, so I Progress. due date end of may ?
(10:48:37) mdamboldt: Yes
(10:48:56) lgodard: anyone else ?
(10:48:56) jsc: i would like to raise the question if we need some ind of beta repository for extensions.
(10:49:27) lgodard: what woul be that beta ?
(10:49:44) lgodard: beta regarding submitters or beta regarding our checking ?
(10:50:26) SunNF: jsc: do you mean a beta repository or a repository for beta extensions. Guess the second one. What about some new cathegory for such extenions?
(10:50:37) lgodard: jsc: this is an important question. do you have some opinion ?
(10:51:09) lgodard: SunNF: i agree. extend and add a "checked by ourselves" icon ?
(10:51:12) jsc: yes , i mean a second repository.
(10:51:21) ***jsc typing
(10:53:54) lgodard: jsc: typing a looooooong text :)
(10:53:58) jsc: The point is that people who have installed an extension don't read the description in detail and probably simply update the extension. The current mechanism would always signal that there is a newer one. If we would be able to differentiate between a stable and a beta/test repository we easier provide the right version to our users. Users who are interested in only stable ext would disable...
(10:54:00) jsc: ...the test/beta/preview repository.
(10:54:37) jsc: I like the mechanism of NB. Where users can easy enable/disable different repositories
(10:54:46) lgodard: what is the difference with an extra tag/property in the reporsitory ?
(10:54:55) bosi a quitté le salon (quit: Read error: 110 (Connection timed out))
(10:54:59) lgodard: NB ?
(10:55:06) lgodard: oh, netbeans
(10:55:18) jsc: and i know that our colleagues working on the report build would like to have such a mechanism to provide repviews
(10:55:32) mdamboldt: I don't like the idea of a second repository.
(10:55:32) mdamboldt: Would be much better to have a separate category for beta stuff in the existing reporsitory as SunNF already suggested.
(10:55:32) mdamboldt: jsc: You can differenciate builds by creating a new submition instead of a new revision. By this users wouldn't be notified if the use 1.x and 2.x Beta is out of an extension.
(10:55:39) jsc: :-) sorry yes i mean NB = NetBeans
(10:56:43) SunNF: mmm, I'm wondering if we would loose a feedback channel for developers if we decouple the repositories. I agree that we need some kind of differentiation for both kinds of extenison, pre final and final ones.
(10:57:33) jsc: why should we confuse the users with new submission of the same thing. if the new version reach the final state it will be simply moved
(10:57:59) lgodard: jsc: or its "beta" tag removed
(10:58:03) SunNF: Implementing a extra tag for this looks less expensive for me.
(10:58:09) lgodard: SunNF: i agree
(10:58:21) mdamboldt: jsc: First you say you won't like to notify stable users about a beta release. Now you say you would!?!??
(10:58:21) SunNF: bosi?
(10:58:24) lgodard: SunNF: and could be extended to other things
(10:58:26) jsc: i think we can simply adapt a working model and don't have to invent the wheel again
(10:58:55) bosi_: here...?
(10:59:23) SunNF: Any opinioin on the effort for a seprate repository vs. a extra tag for pre-releases?
(10:59:36) jsc: mdamnboldt: no i want to let it up to the user. The user can decide if want to be informed or not
(11:00:04) lgodard: jsc: fine grained at the extension level
(11:00:09) bosi_: Extra tag is much easier, than extra repository; there could be an extra feed generated for the beta tag, that my be added to the extension manager?
(11:00:13) ***mdamboldt why complicate when we can keep it simple?
(11:00:19) lgodard: jsc: i may be interrested in a beta for an extension and not an other
(11:00:34) lgodard: bosi_: agree
(11:02:16) jsc: well, if you think we don't need i can live with that. It's just my opinion and have enough experience with the NB model and i like it. That's all and i think it's better than ours.
(11:02:26) SunNF: Are we able to agree on the requirement for diferntiation of both states, regardless how we will implement it?
(11:02:39) ***jsc i lost a lot of words today
(11:02:48) lgodard: SunNF: yes. and then ?
(11:02:50) jsc: yes
(11:03:14) SunNF: so, lets work on a proposal for the implementation offline.
(11:03:20) lgodard: i propose that the 2 models be briefly described
(11:03:31) lgodard: on mailin list
(11:03:42) lgodard: website@extensions ?
(11:03:50) mdamboldt: SunNF: Yes. And as I said before, everything we need is already there from my point of view. Just the extra category is missing in my opinion.
(11:05:22) lgodard: ok ?
(11:06:06) lgodard: there is a last small note : Typo's on thank you screen : mail from sophie, who takes care ?
(11:06:37) bosi_: ups, forgott about it; willl take care :-)
(11:06:45) lgodard: bosi_: great :)
(11:06:54) lgodard: so, anyone else ?
(11:07:17) lgodard: end in 5 seconds
(11:07:24) lgodard: 4
(11:07:29) lgodard: 3
(11:07:32) lgodard: 2
(11:07:35) jsc: 3, 2, 1, bye
(11:07:36) lgodard: 1
(11:07:40) lgodard: 0
(11:07:45) lgodard: bye all
(11:07:48) SunNF: bye
(11:07:52) mdamboldt: bye
(11:08:02) bettina-h:  bye