Re: AOO volunteers: essential skills and tasks
Hi. I think your md pages are SUPERwhat I suggested was an additional wiki page (actually someone else called it postoffice) where we put small tasks that need to be translated / written etc. So I see your pages go hand in hand with Wiki pages, just too different levels of interaction with the community. jan On 31 October 2012 16:59, Rob Weir robw...@apache.org wrote: On Wed, Oct 31, 2012 at 11:51 AM, Kay Schenk kay.sch...@gmail.com wrote: On 10/28/2012 04:30 PM, Rob Weir wrote: On Sun, Oct 28, 2012 at 6:29 PM, Andrea Pescetti pesce...@apache.org wrote: On 23/10/2012 Rob Weir wrote: New Volunteer Orientation root page: http://incubator.apache.org/openofficeorg/orientation/ This is an excellent resource. But we received a few requests from prospective volunteers this weekend and I'm believing it would be overwhelming to point them there. I still believe these documents are excellent, but probably they are assuming our volunteer is above average, or at least willing to engage deeply with the project. They would be perfect for me, for you, or for a newcomer like Jan who has the skills and the mindset to understand in detail how things work. And how do we know in advance which volunteers are like Jan and which are not? I think we should find some way to point them to the info and say that they are welcome to jump in and ignore this all, or skim it in parallel with direct participation, or read through this stuff first. It is entirely up to them. But generally, the more one needs to interact with other project participants and other systems and even other parts of Apache, the more this information becomes useful. Although not stated, one could almost say that Level 4 would be becoming a Committer. So you are correct that this is a track for a more determined volunteer, But we will also have (and we do have: most volunteers I see on the mailing lists in Italian fall in this category) volunteers who don't care that much about OpenOffice as a project: they use the product and just want to give something back. They want to scratch an itch, or just to do something, but they are very task-oriented: they want something to do rather than something to read. For example, we may have translation volunteers who would be perfectly satisfied if we e-mail them a PO file and tell them to grab POEdit and send the file back; and then they would consider a deeper engagement, but not earlier. Translation volunteers are different in many ways, but even there I think we need some solid orientation material. They won't go far before wondering why they cannot write to Pootle and the website, but others can. That leads us into discussion of roles at Apache, etc. And we really need to expose them to the Apache License at the earliest opportunity. We do no one any favors if we're passing around PO files via private mail, and receiving translations without any public record of contribution. In any case, this is an issue we've had for a while. Becoming a Committer is a higher hurdle than is appropriate for most translation volunteers, due to iCLA, etc. The orientation guides did not create this problem, they merely remind us of it. And indeed they are not totally wrong: knowing how the Apache Board works is not needed to be able to translate a press release, or a few OpenOffice strings, into Italian. Could it be that we need a practical entry point for people who want to help and just want to do it immediately? Placing these information at level 3 of the Volunteer Orientation seems too much for volunteers who want to jump in and do something (while, again, the orientation guide is excellent for a skilled, determined volunteer). Since level 3 for translators does not exist yet, it may be too early to say whether or not is practical. (I hope it will be practical). If we make it self-contained, it may be possible for it be consulted on its own for someone who is not seeking deeper engagement with the project. -Rob Regards, Andrea. Rob, I still support this whole notion. But, maybe it would be better to go with more of a checklist style instead of the in-depth explanations you have in this document. What if you ported this to the wiki (Jan suggested this as well. cwiki is easiest for me but I have no object to wiki.openoffice.org) so those of us that are interested can more easily contribute to this worthwhile guide. Of course you are free to start whatever wiki page you wish. But I'll be continuing with the mdtext pages I've started. This is based on my experience with providing orientation to many of our Symphony developers on how Apache projects work and how to participate in such a community. This approach works. Other approaches might work for others as well. But I'm going to
[question] build infra structure.
Hi I have been searching for detailed internal information about how the build process works with build and dmake (gnumake). I have seen the relationship in the single directories (prj/build.lst prj/d.lst and makefile.mk), but I cannot find a central makefile. If I understand life, there should be a central makefile, telling e.g. how .cpp is translated to .o Can somebody please point me in the direction, or tell me if it done in a different way ? My reason for asking is that I need to add a set of new standard rules for localization (.xhlp - .po ) Thanks in advance. Jan
Re: Have you been contacted via private email and discouraged from participating on the OpenOffice project?
+1, what can I say apart from I am still here, and I mean to stay with AOO for a long time. Jan. On 1 November 2012 15:18, Rob Weir robw...@apache.org wrote: I'm hearing that some project volunteers, especially new ones, are being contacted by certain external parties, who then try to discourage them from contributing to the Apache OpenOffice project. I'm hearing that similar notes have been sent out to those who submitted listings to our new Consultants Directory, also discouraging them from involvement in the project. This is my personal view on this matter, for what it is worth. I think we all would agree that such techniques are deplorable and bring disrepute to the individuals involved, and to the project that sanctions such techniques. If you recall we had a similar wave of such unprofessional behavior a few months ago, when certain external parties were contacting journalists who mentioned OpenOffice and telling them that it was no longer being developed and to link to a different product instead. I any case, if you are receiving such FUD yourself, I'd encourage you to simply post it to this mailing list, or to your blog, or some other public website. Daylight is the best antiseptic as they say. I am not a medical doctor, but I do believe that FUD exposed to public scrutiny loses its potency. But FUD ignored is FUD that spreads. Regards, -Rob
Re: OpenOffice Developer Room (devroom) at FOSDEM
A brilliant idea, especially if I may copy some of your slides... I am still fumbling how the build works, and to be honest (NOT to criticize anyone) I am not impressed. Just one thing: I do a build --all, which comes back OK, then I do a second build --all and to my surprise it generates a couple of libraries again..I assumed I had missed an error, so I tried it a third time, same thing happened, libraries was built. In my opion (and according with normal makefile schemes) once it completes without errors, it should not build anything a second time. But putting that aside, I would be happy to focus on localization together with jürgen, but if it is something you want to do it yourself thats ok with me. Jan. On 1 November 2012 16:55, Andre Fischer awf@gmail.com wrote: On 30.10.2012 22:10, jan iversen wrote: Just for info, Juergen told me that he was going to talk about l10n on apacheCon, so I suggested that we could make a speech at FOSDEM, because at that time the new workflow is hopefully ready or so close that we know all details. A good theme for a main speech would be how the handle the build (and release) process with internationalization in a big project like AOO. Hi Jan, I will be talking at ApacheCon EU about the AOO build system and only briefly mention l10n (how it works today). Maybe you want to give a similar talk at FOSDEM but with a strong focus on l10n? -Andre
Re: Have you been contacted via private email and discouraged from participating on the OpenOffice project?
Please excuse me, I think I know the difference between hooligans and people who are just blowing hot air. To be honest, at the moment AOO does NOT have a great deal of momentum, and have (I think) lost a quite a lot of reputation among developers. That is something we have to remedy, not by glittering folders, or smart marketing, but by showing the developers, that we really care about their contributions. If I may say so, some developers might see the apache way as a limitation, which my experience during the last month somewhat confirms, I think we really need to focus on the community instead of telling people about legal issues, but about getting a product that still can out beat the big (costly) products out there. Do NOT forget some state institutions in EU choose OpenOffice against other, but today I would not be so sure !!! Sorry for the outburst, but I am used to say what I think, and I really really want AOO to be the opensource project, as it was in the past. Lets not forget why we are all here. Jan On 1 November 2012 17:20, RGB ES rgb.m...@gmail.com wrote: 2012/11/1 Rob Weir robw...@apache.org I'm hearing that some project volunteers, especially new ones, are being contacted by certain external parties, who then try to discourage them from contributing to the Apache OpenOffice project. I'm hearing that similar notes have been sent out to those who submitted listings to our new Consultants Directory, also discouraging them from involvement in the project. This is my personal view on this matter, for what it is worth. I think we all would agree that such techniques are deplorable and bring disrepute to the individuals involved, and to the project that sanctions such techniques. If you recall we had a similar wave of such unprofessional behavior a few months ago, when certain external parties were contacting journalists who mentioned OpenOffice and telling them that it was no longer being developed and to link to a different product instead. I any case, if you are receiving such FUD yourself, I'd encourage you to simply post it to this mailing list, or to your blog, or some other public website. Daylight is the best antiseptic as they say. I am not a medical doctor, but I do believe that FUD exposed to public scrutiny loses its potency. But FUD ignored is FUD that spreads. There is and always will be people who do not understand what an opensource project is and behave like hooligans defending their soccer team. I hope they are just individuals and nothing more, but I fully agree to put each case under daylight. Regards Ricardo Regards, -Rob
Re: [question] build infra structure.
See below please. THANKS for your VERY informative answer, it helped me a lot. I was of the simple idea, that we pursued a simple build process made up of gnuMake and an addon to gather for the shortcoming of gnumake in respect of cascaded makefiles. I hope to see your presentation on video later, due to personal budget restriction (dont we all have that) I cannot participate. Jan. On 1 November 2012 17:44, Andre Fischer awf@gmail.com wrote: On 31.10.2012 22:20, jan iversen wrote: Hi I have been searching for detailed internal information about how the build process works with build and dmake (gnumake). I have seen the relationship in the single directories (prj/build.lst prj/d.lst and makefile.mk), but I cannot find a central makefile. If I understand life, there should be a central makefile, telling e.g. how .cpp is translated to .o Pah, who needs a central makefile if he can have a Perl file instead :-) Sorry, I could not resist. I am currently preparing a talk for ApacheCon about the AOO build system and it is somewhat depressing to see how bizarre some things are. It´s quite OK, I learn fast :-) (and being a dane I like that kind of jokes/hints) If I find the time after ApacheCon then I will turn my talk into a Wiki page or one or several blog posts. Here is the short version. First there is configure and bootstrap. But I think that you have mastered that step already. Then comes the actual building. The central makefile is main/solenv/bin/ build.pl, yes, a Perl script. It reads module/prj/build.lst files to a) determine the dependency between modules and (just the first line) b) find the directories inside each module that have to be built. (all other lines) build.pl starts at main/instsetoo_native/prj/buil**d.pl http://build.pl and follows the dependency to other modules. build.pl can handle multi process builds and uses the module dependency graph to build modules in the right order. It can do partial builds: build --all --from module ignores all modules before module when building AOO (in the linearization of the dependency graph) build --all called in another module than instsetoo_native builds all dependencies and stops when the current module is built. build.pl calls dmake for every module, regardless of whether they are dmake or gbuild modules. - For dmake modules it calls dmake for all directories listed in prj/build.lst - For gbuild modules it does the same but prj/build.lst only contains one entry which points to util/makefile.mk This util/makefile.mk then chains GNU make for module/Makefile gbuild modules have all their makefiles in their top level directory. One makefile per library or other main targets. Why dont we just use dmake/gnumake, have a makefile in each directory which includes a master makefile ? Both dmake and gbuild distinguish between data and build logic. The modules usually contain only descriptions of which source files have to be compiled and which libraries are to be linked. How that is done, on all the different platforms, compilers, environment variables is handled by makefiles in solenv/incfor dmake solenv/gbuild for gbuild A I wrong in saying that the bulid list and delivery list could just as easily have been expressed as a target in makefile.in ??? Please forgive me, I am (as one who looks at the process with new eyes) just floating ideas ? The last part of the build process is the creation of installation sets. It is triggered by instsetoo_native/util/makefile**.mkhttp://makefile.mkwhich basically just calls solenv/bin/ make_installer.pl with a cleverly selected bunch of parameters. make_installer.pl uses a larger number of Perl modules under solenv/bin/modules/installer which then do the actual work of collecting the relevant files, copying them into a temporary directory into a runnable office, and finally packing them into a package that fits the target platform. I am aware that the above is still very terse. I am happy to answer any questions (if I know the answer). Thanks again, you actually helped me a lot Regards, Andre Can somebody please point me in the direction, or tell me if it done in a different way ? My reason for asking is that I need to add a set of new standard rules for localization (.xhlp - .po ) Thanks in advance. Jan
Re: [question] build infra structure.
you See below please. On 1 November 2012 18:18, Andre Fischer awf@gmail.com wrote: On 01.11.2012 17:57, jan iversen wrote: See below please. THANKS for your VERY informative answer, it helped me a lot. I was of the simple idea, that we pursued a simple build process made up of gnuMake and an addon to gather for the shortcoming of gnumake in respect of cascaded makefiles. We are in the process of migrating from dmake to GNU make. When that is finished then we will have essentially one single makefile. Well, there will be one top level makefile that includes all the other makefiles. But there will not one make process that starts other makes in subprocesses. That would be evil, or so I have been told, see http://wiki.openoffice.org/**wiki/Build_System_Analysishttp://wiki.openoffice.org/wiki/Build_System_Analysis I am in the process of changing the l10n process. Currently it runs on one makefile that searches all directories, I want to change that to a target in every local makefile (build.lst). Can I attach myself to your progress, or would you suggest that I attach my development to the current build process. my timeline is somewhat around new year. I hope to see your presentation on video later, due to personal budget restriction (dont we all have that) I cannot participate. Sorry to hear that, I would have liked to meet you. Well if you come to FOSDEM, we can have a long chat. My problem is that I am currently only a contributor so that ticket alone is 600,- EUR. I am also prepared for google/skype videochats. Jan. On 1 November 2012 17:44, Andre Fischer awf@gmail.com wrote: On 31.10.2012 22:20, jan iversen wrote: Hi I have been searching for detailed internal information about how the build process works with build and dmake (gnumake). I have seen the relationship in the single directories (prj/build.lst prj/d.lst and makefile.mk), but I cannot find a central makefile. If I understand life, there should be a central makefile, telling e.g. how .cpp is translated to .o Pah, who needs a central makefile if he can have a Perl file instead :-) Sorry, I could not resist. I am currently preparing a talk for ApacheCon about the AOO build system and it is somewhat depressing to see how bizarre some things are. It´s quite OK, I learn fast :-) (and being a dane I like that kind of jokes/hints) If I find the time after ApacheCon then I will turn my talk into a Wiki page or one or several blog posts. Here is the short version. First there is configure and bootstrap. But I think that you have mastered that step already. Then comes the actual building. The central makefile is main/solenv/bin/ build.pl, yes, a Perl script. It reads module/prj/build.lst files to a) determine the dependency between modules and (just the first line) b) find the directories inside each module that have to be built. (all other lines) build.pl starts at main/instsetoo_native/prj/**buil**d.pl http://build.pl and follows the dependency to other modules. build.pl can handle multi process builds and uses the module dependency graph to build modules in the right order. It can do partial builds: build --all --from module ignores all modules before module when building AOO (in the linearization of the dependency graph) build --all called in another module than instsetoo_native builds all dependencies and stops when the current module is built. build.pl calls dmake for every module, regardless of whether they are dmake or gbuild modules. - For dmake modules it calls dmake for all directories listed in prj/build.lst - For gbuild modules it does the same but prj/build.lst only contains one entry which points to util/makefile.mk This util/makefile.mk then chains GNU make for module/Makefile gbuild modules have all their makefiles in their top level directory. One makefile per library or other main targets. Why dont we just use dmake/gnumake, have a makefile in each directory which includes a master makefile ? I guess there are historical reasons for that. And then there is the not-invented-here syndrome. I have made an experiment a few months ago in which I wrote a Perl script that reads all prj/build.lst files and creates one GNU makefile that did what build --all does. Worked like a charm. It just has not many advantages over build.pl. Especially when we proceed with the dmake to gbuild transition and will have the centeral makefile in a few months. Both dmake and gbuild distinguish between data and build logic. The modules usually contain only descriptions of which source files have to be compiled and which libraries are to be linked. How that is done, on all the different platforms, compilers, environment variables is handled by makefiles in solenv/incfor dmake solenv/gbuild for gbuild A I wrong in saying that the bulid list and delivery list
CMS diff: Welcome to the localization (l10n) project
Clone URL (Committers only): https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://ooo-site.apache.org/l10n-new%2Findex.mdtext jan iversen Index: trunk/content/l10n-new/index.mdtext === --- trunk/content/l10n-new/index.mdtext (revision 1404729) +++ trunk/content/l10n-new/index.mdtext (working copy) @@ -30,21 +30,9 @@ - [UI][2] - [Help][3] -## The site is undergoing a major overhaul! -We are working hard at a new workflow, that involves translators more -directly in the release process. This site plays a major role in the new -workflow, so please accept our apoligies for the state of the site. -All old content can be found under the menupoint archive. -## Questions or comments? -Contact us [ooo-l...@incubator.apache.org][4] or subscribe -[ooo-l10n-subscr...@incubator.apache.org][5]. - - [1]: http://en.wikipedia.org/wiki/Internationalization_and_localization [2]: https://translate.apache.org/projects/OOo_34/ [3]: https://translate.apache.org/projects/OOo_34_help/ -[4]: mailto:ooo-l...@incubator.apache.org -[5]: mailto:ooo-l10n-subscr...@incubator.apache.org
CMS diff:
Clone URL (Committers only): https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://ooo-site.apache.org/l10n-new%2Fleftnav.mdtext jan iversen Index: trunk/content/l10n-new/leftnav.mdtext === --- trunk/content/l10n-new/leftnav.mdtext (revision 1404729) +++ trunk/content/l10n-new/leftnav.mdtext (working copy) @@ -1,12 +1,18 @@ divid: leftnav -# Some Header 1 +# News +## The site is undergoing a major overhaul! +We are working hard at a new workflow, that involves translators more +directly in the release process. This site plays a major role in the new +workflow, so please accept our apologies for the state of the site. + +# Links + - [How To Join](/l10n-new/how_to_join.html) - [Support](/l10n-new/support.html) - - [Team](/l10n-new/team.html) -# Some Header 2 +## Questions or comments? - - [Documentation](/l10n-new/documentation.html) - - [FAQ](/l10n-new/faq.html) +Contact us [ooo-l...@incubator.apache.org][mailto:ooo-l...@incubator.apache.org] or subscribe +[ooo-l10n-subscr...@incubator.apache.org][ mailto:ooo-l10n-subscr...@incubator.apache.org].
Re: Have you been contacted via private email and discouraged from participating on the OpenOffice project?
Hi Dave. Even though I have stopped my companies, I still have many other things to do than working on AOO, and when I had my companies I had limited time, so I can for sure follow you. Today I am just trying to help open source as such, because it has helped me a lot in my career. And to answer your question, yes I do have some ideas (but they might be wrong), I have listed some of the important ones below: - We need to focus more on people who want to help, instead of using all the legal stuff (which are necessary) as a buffer not to move things. (e.g. I got 2 volunteers working on a danish translation, highly motivated, now we are discussing details about how to release the stuff). I think Rob is having a lead here with his new web pages. - We do NOT want a war of religions between AOO and others, ASF is well known, upper end of free software, so we should be publicly asking for collaboration. - I think events like ApacheCon is nice, but events like FOSDEM is quite a lot more important for the ordinary openSource developer. - I would like to see more marketing for developers, instead of businesses...I think we need to get back to roots where a developers think its fun, and pride to develop AOO. We could easily e.g. make challenges like who can solve this problem. I am new to AOO (so I am either interfering or bringing in new views), but I have quite some years of experience with openSource and I am a strong believer of ASF. The apache way is in many ways a limitation, but at the end it is the guarantee for a better end-user product. Please accept my apologies, if I have broken n-policies, but I think the question from Dave was well placed, and well formulated so it deserved a straight answer. Jan. On 1 November 2012 20:51, Dave Fisher dave2w...@comcast.net wrote: Hi Jan, We are all here as individuals with various and different amounts of time and energy. Many are employed to work on OpenOffice, but many like me are volunteers who have demanding day jobs. The key part of the Apache Way is that leadership comes from DOING and COMMUNICATING. You are new here with lots of admirable energy and work! This is what acquires merit in an Apache project! Since we ultimately can only control ourselves, do you have any suggestions about how we can more actively encourage participation? Best Regards, Dave On Nov 1, 2012, at 9:38 AM, jan iversen wrote: Please excuse me, I think I know the difference between hooligans and people who are just blowing hot air. To be honest, at the moment AOO does NOT have a great deal of momentum, and have (I think) lost a quite a lot of reputation among developers. That is something we have to remedy, not by glittering folders, or smart marketing, but by showing the developers, that we really care about their contributions. If I may say so, some developers might see the apache way as a limitation, which my experience during the last month somewhat confirms, I think we really need to focus on the community instead of telling people about legal issues, but about getting a product that still can out beat the big (costly) products out there. Do NOT forget some state institutions in EU choose OpenOffice against other, but today I would not be so sure !!! Sorry for the outburst, but I am used to say what I think, and I really really want AOO to be the opensource project, as it was in the past. Lets not forget why we are all here. Jan On 1 November 2012 17:20, RGB ES rgb.m...@gmail.com wrote: 2012/11/1 Rob Weir robw...@apache.org I'm hearing that some project volunteers, especially new ones, are being contacted by certain external parties, who then try to discourage them from contributing to the Apache OpenOffice project. I'm hearing that similar notes have been sent out to those who submitted listings to our new Consultants Directory, also discouraging them from involvement in the project. This is my personal view on this matter, for what it is worth. I think we all would agree that such techniques are deplorable and bring disrepute to the individuals involved, and to the project that sanctions such techniques. If you recall we had a similar wave of such unprofessional behavior a few months ago, when certain external parties were contacting journalists who mentioned OpenOffice and telling them that it was no longer being developed and to link to a different product instead. I any case, if you are receiving such FUD yourself, I'd encourage you to simply post it to this mailing list, or to your blog, or some other public website. Daylight is the best antiseptic as they say. I am not a medical doctor, but I do believe that FUD exposed to public scrutiny loses its potency. But FUD ignored is FUD that spreads. There is and always will be people who do not understand what an opensource project is and behave like hooligans defending their soccer team
Re: AOO.Next IBM Priorities
Thanks for the note, however knowing IBM I had hoped that one of the official goals was to help the development part of the community to get stabilized. I acknowledge that it is important for IBM to get an output of invested energy/time/money, but I think IBM would benefit not only from features but also from the soft points of helping the community. that being said in response to your IBM HAT, but I do feel that you and other IBM Fellows still do a great job in getting the community to prosper. Jan. On 1 November 2012 17:45, robert_w...@us.ibm.com wrote: A quick note, wearing my IBM hat. We (IBM) have consulted with customers, internal users, other IBM product teams, on what our (IBM's) development priorities should be for the next AOO release. Obviously, we're not the only ones with priorities or interests or opinions. We don't make AOO decisions by ourselves. But we want to be transparent about what our own priorities are, for our employees participating in the AOO community, and what they will be focusing on. As we did with AOO 3.4.0 and 3.4.1, we'll be putting the details onto the wiki over the next couple of weeks. You'll hear more at ApacheCon, but I wanted you to hear it hear first. Our top priorities: -- Improve the install and deployment experience, especially by supporting digital signatures on installs, and introducing a new incremental update feature, so users are not required to download and install a full image for just a minor update. -- A major UI enhancement, a sidebar framework for the editors, ported over from Symphony, and including an API. If you recall, Symphony won quite a lot of praise for its UI, and much of this was due to the sidebar panel. I think we can make a good argument that this approach, say compared to the MS Office ribbon is a better use of screen real-estate, especially as we see more frequent use of wide screen displays. -- Improved Table of Contents in Writer -- Improved system integration on Windows and MacOS, including possible adoption of gestures. -- IAccessible2 bridge, ported over from Symphony, to improve accessibility. This is a major effort, but very important. -- Closer integration of clipart and template libraries with user experience. -- Update branding and visual styling, contemporary and compelling, fresh and relevant. -- Social integration, allow our users to quickly and easily share their thoughts in a way that compliment their commercial social behavior. Explore the integration of consumer service-specific capabilities as well as generic Share... actions. -- And many other smaller items Obviously the release date for this cannot be pinned down so early, and releasing is PMC decision, not an IBM one. But we think that this work could be completed and tested for a release in the March/April 2013 time-frame. And the scope of the release might be significant enough to warrant a 4.0 designation. In any case, we'll soon set up a page on the wiki to collect these items. As always, I invite you to add your own priorities to the wiki, things that you would like to work on. This could be a new feature. Or, if one of the above items sound interesting to you, we always welcome help designing and implementing these features. Regards, -Rob
Re: extensions and translations.
Can standard loosely be defined as an extension: - is developed by people who have signed ICLA - uses the apache license header in the source files - is of interest to the general public in different countries - is willing to let the source be controlled/reviewed by committer. - accept a vote by the committers to be accepted If those points are fuillfilled we could add the project to swext, and then it would automatically be integrated in the build and l10n process. Please help me out here, I am not sure if that is enough for the apache way. Jan. On 1 November 2012 21:24, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 11/01/2012 01:17 PM, schrieb Rob Weir: On Thu, Nov 1, 2012 at 3:52 AM, Jürgen Schmidtjogischm...@gmail.com wrote: On 11/1/12 12:39 AM, Marcus (OOo) wrote: Am 10/27/2012 01:17 AM, schrieb jan iversen: I see, I have to get used to this license issues (a long time ago I believed open source was just open source, then I joined an apache project). never mind. Would it be to our advantage if we offered third party developers (that is how I see extension developers) the possibility to register a language file and get it translated as part of the language packs ? Of course it would be to our advantage; or let's say for the project and software. A lot of extensions would be available in many languages. However, I don't know where we should draw the line to set a limit. When we select here and there some extensions, then the other developers will ask why not their extensions. It's quite simple I would say, if people want develop extensions under ALv2 and want to contribute the code to the project. We can easy create a special section in our repo where we can host them. But this means they have to be handled in the same way as all other stuff here. Means a new release have to be voted... +1 I think the important thing is this: We don't just want code. We want communities. So if an extension author thinks that their extension is generally useful and he/she wants to join the AOO community and work on the extension here, and allow others to work on it as well, then this is good. Of course, +1. We can have a set of standard extensions. So, we just need to define the standard. Marcus And IMHO it's not possible to translate all strings for all extensions. But maybe others here have a great idea? we can't probably provide it and I think we have to do enough ;-). But I can think of an alternative service hosted somewhere else. Juergen Or should we just say extension developers does not concern us (and help AOO get more used) so we just look the other way ? Maybe the right way is somewhere in the middle. Yeah, maybe. ;-) Marcus On 27 October 2012 00:58, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/27/2012 12:36 AM, schrieb jan iversen: While doing an update to the l10n workflow I think I found a slight problem. Extensions offers the capability to integrate/extend our UI. Assuming somebody writes an extension, and publishes it on http://www.openoffice.org/extensions/http://www.openoffice.org/**extensions/ http://www.**openoffice.org/extensions/http://www.openoffice.org/extensions/ how does that get integrated into the translation process ? Simply, not at all. As far as I can see the sources are not integrated into our build --all --with-lang. Right. If I am right that they are not part of the general translation, then is that per design so or should it be different ? Yes, this is by design. Extensions are offered to extent your AOO install at any point of time. These are developed by people that do not have to belong to our project (when we put aside some exceptions). They can act independently. And therefore they are allowed to (or have to ;-) ) do all on their own; incl. translation. That applies for all extensions and templates available on: - http://extensions.services.**o**penoffice.org http://openoffice.org http://**extensions.services.**openoffice.orghttp://extensions.services.openoffice.org - http://templates.services.**op**enoffice.org http://openoffice.org http://templates.**services.openoffice.orghttp://templates.services.openoffice.org I might be following a wrong track here, but please forgive me for trying to make the l10n process as complete as I can. Don't panic. That's a great goal and everybody is thankful to you for doing this task. Marcus
Re: CMS diff: Welcome to the localization (l10n) project
I do not ignore qualified input !! I will just have to find a way of making a right-nav bar, something that Ariel did not provide (but still it was a very helpful job). I will download and try to make the changes. Jan. On 1 November 2012 21:40, Rob Weir robw...@apache.org wrote: I committed this. A did a little clean up. The left nav wasn't handling the long email list addresses well (wasn't wrapping them) so I rewrote to user shorter names. It is starting to look good: http://www.openoffice.org/l10n-new/ Good work! My unsolicited feedback, which you are free to ignore, is that the news might go better on the right, as another column. That way the links on the left are always at the top of their column, which seems more natural to me. That also gives space to have more than one news story without displacing navigation elements. -Rob On Thu, Nov 1, 2012 at 3:34 PM, jan iversen anonym...@apache.org wrote: Clone URL (Committers only): https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://ooo-site.apache.org/l10n-new%2Findex.mdtext jan iversen Index: trunk/content/l10n-new/index.mdtext === --- trunk/content/l10n-new/index.mdtext (revision 1404729) +++ trunk/content/l10n-new/index.mdtext (working copy) @@ -30,21 +30,9 @@ - [UI][2] - [Help][3] -## The site is undergoing a major overhaul! -We are working hard at a new workflow, that involves translators more -directly in the release process. This site plays a major role in the new -workflow, so please accept our apoligies for the state of the site. -All old content can be found under the menupoint archive. -## Questions or comments? -Contact us [ooo-l...@incubator.apache.org][4] or subscribe -[ooo-l10n-subscr...@incubator.apache.org][5]. - - [1]: http://en.wikipedia.org/wiki/Internationalization_and_localization [2]: https://translate.apache.org/projects/OOo_34/ [3]: https://translate.apache.org/projects/OOo_34_help/ -[4]: mailto:ooo-l...@incubator.apache.org -[5]: mailto:ooo-l10n-subscr...@incubator.apache.org
Re: extensions and translations.
see below please. On 1 November 2012 22:21, Rob Weir robw...@apache.org wrote: On Thu, Nov 1, 2012 at 5:07 PM, jan iversen jancasacon...@gmail.com wrote: Can standard loosely be defined as an extension: - is developed by people who have signed ICLA - uses the apache license header in the source files - is of interest to the general public in different countries - is willing to let the source be controlled/reviewed by committer. - accept a vote by the committers to be accepted If those points are fuillfilled we could add the project to swext, and then it would automatically be integrated in the build and l10n process. Please help me out here, I am not sure if that is enough for the apache way. There are probably two degrees of standard or official extensions. 1) An extension that is released with our binaries, e.g., it is available out-of-the-box, either automatically installed, or available as an option in the installer. That would be things like wiki publisher in swext, that still have the sun license and not the apache license. But that what actually what I was thinking about, and of course these extension MUST be part of the apache demands. We might include include in the setup package, but it should not be automatically installed, if that was the case the end-user would see it as an integrated part, and not an add-on. We should not take responsibility for the extension, but simply offer it. 2) An extension that is developed and released by the project, and published in the extension repository. This is the current standard and should not be changed. the add on is optional The process for these would be nearly identical, differing only on whether it is released standalone or bundled with the full AOO installer. and not to forget, the possibility of getting the UI translated and available all over the world. Can we collect statistics about which extensions is installed how often ?? -Rob Jan. On 1 November 2012 21:24, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 11/01/2012 01:17 PM, schrieb Rob Weir: On Thu, Nov 1, 2012 at 3:52 AM, Jürgen Schmidtjogischm...@gmail.com wrote: On 11/1/12 12:39 AM, Marcus (OOo) wrote: Am 10/27/2012 01:17 AM, schrieb jan iversen: I see, I have to get used to this license issues (a long time ago I believed open source was just open source, then I joined an apache project). never mind. Would it be to our advantage if we offered third party developers (that is how I see extension developers) the possibility to register a language file and get it translated as part of the language packs ? Of course it would be to our advantage; or let's say for the project and software. A lot of extensions would be available in many languages. However, I don't know where we should draw the line to set a limit. When we select here and there some extensions, then the other developers will ask why not their extensions. It's quite simple I would say, if people want develop extensions under ALv2 and want to contribute the code to the project. We can easy create a special section in our repo where we can host them. But this means they have to be handled in the same way as all other stuff here. Means a new release have to be voted... +1 I think the important thing is this: We don't just want code. We want communities. So if an extension author thinks that their extension is generally useful and he/she wants to join the AOO community and work on the extension here, and allow others to work on it as well, then this is good. Of course, +1. We can have a set of standard extensions. So, we just need to define the standard. Marcus And IMHO it's not possible to translate all strings for all extensions. But maybe others here have a great idea? we can't probably provide it and I think we have to do enough ;-). But I can think of an alternative service hosted somewhere else. Juergen Or should we just say extension developers does not concern us (and help AOO get more used) so we just look the other way ? Maybe the right way is somewhere in the middle. Yeah, maybe. ;-) Marcus On 27 October 2012 00:58, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/27/2012 12:36 AM, schrieb jan iversen: While doing an update to the l10n workflow I think I found a slight problem. Extensions offers the capability to integrate/extend our UI. Assuming somebody writes an extension, and publishes it on http://www.openoffice.org/extensions/ http://www.openoffice.org/**extensions/ http://www.**openoffice.org/extensions/ http://www.openoffice.org/extensions/ how does that get integrated into the translation process ? Simply, not at all. As far as I can see the sources are not integrated into our build --all --with-lang. Right
Re: CMS diff: Welcome to the localization (l10n) project
THANKS, you are really super !! Yes I would like the style of the the news bar, do we need to add a style sheet. I am flying a bit blindfolded here, being a contributor, not being able to do the things myself, so thanks again for your help. One question: When you commit to SVN, I think you also need to publish it. but how come CMS is not updated... jan. On 1 November 2012 22:31, Ariel Constenla-Haile arie...@apache.org wrote: On Thu, Nov 01, 2012 at 10:11:05PM +0100, jan iversen wrote: I do not ignore qualified input !! I will just have to find a way of making a right-nav bar, something that Ariel did not provide (but still it was a very helpful job). I will download and try to make the changes. It's rather simple: - add the right navigation MarkDown file in ooo-site/content/l10n-new/rightnav.mdtext it must have the header divid:rightnav - instruct ooo-site/templates/l10n-new/ssi.mdtext to include it, adding a line like this: rightnav:/l10n-new/rightnav.html Anyway I committed the changes right now :) May be we can style the right bar to look like the news bar on the main index. Regards -- Ariel Constenla-Haile La Plata, Argentina
Re: CMS diff: Welcome to the localization (l10n) project
Can someone please publish rightnav (that ariel committed) so I can edit it with cms. thanks in advance. Jan. On 1 November 2012 22:31, Ariel Constenla-Haile arie...@apache.org wrote: On Thu, Nov 01, 2012 at 10:11:05PM +0100, jan iversen wrote: I do not ignore qualified input !! I will just have to find a way of making a right-nav bar, something that Ariel did not provide (but still it was a very helpful job). I will download and try to make the changes. It's rather simple: - add the right navigation MarkDown file in ooo-site/content/l10n-new/rightnav.mdtext it must have the header divid:rightnav - instruct ooo-site/templates/l10n-new/ssi.mdtext to include it, adding a line like this: rightnav:/l10n-new/rightnav.html Anyway I committed the changes right now :) May be we can style the right bar to look like the news bar on the main index. Regards -- Ariel Constenla-Haile La Plata, Argentina
CMS diff:
Clone URL (Committers only): https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://ooo-site.apache.org/l10n-new%2Ftopnav.mdtext jan iversen Index: trunk/content/l10n-new/topnav.mdtext === --- trunk/content/l10n-new/topnav.mdtext(revision 1404890) +++ trunk/content/l10n-new/topnav.mdtext(working copy) @@ -8,4 +8,4 @@ [m0]: /l10n-new/documentation.html L10n documentation [m1]: /l10n-new/support.htmlLocalization support [m2]: /l10n-new/team.html Apache OpenOffice in your Native Language -[m3]: /l10n-new/archive/index.html Old site +
Re: CMS diff: Welcome to the localization (l10n) project
Just sent off the last change, so now the site is ready in my opinion. There seems to be some fuzz about (on l10n list) whether or not, this was a good idea at all, but if the community likes the layout and the content I have transferred, then please rename or remove l10n and replace it with l10n-new. Jan. On 2 November 2012 00:03, Ariel Constenla-Haile arie...@apache.org wrote: On Thu, Nov 01, 2012 at 11:36:20PM +0100, jan iversen wrote: I would love to publish it myself, but I dont have the karma to do so (I am a contributor). I have updated CMS, no luck ! I published the site, please try again. Nevertheless, and AFAIK, even when you log in as anonymous user your working copy can be updated, and is not completely transient (I can't find the mail right now, but anonymous working copies have a lifetime even if you logout). But looking at staging, did not do the complete trick (I cannot see rightnav), It's there http://ooo-site.staging.apache.org/l10n-new/ and also on the main site, since I published. But unpublished svn commmitts get reflected on staging. Regards -- Ariel Constenla-Haile La Plata, Argentina
Re: AOO volunteers: essential skills and tasks
+1, it is a very intuitive page, and seems easy to link to passing project etc. jan On 2 November 2012 02:40, Rob Weir robw...@apache.org wrote: On Thu, Nov 1, 2012 at 7:52 PM, Andrea Pescetti pesce...@apache.org wrote: On 30/10/2012 Guy Waterval wrote: But for other people who will occasionally participate, why not a Post Office where they could register (for security reasons, acceptation of the license, etc.). When they have time, they can visit the Post Office to see the list of to do tasks, and they can download for instance a translation job. This has been a recurring request, a sort of web application acting as employment agency: matching skills and tasks. Done properly (and with an adequately smart user interface) it would indeed help in attracting new volunteers. I wonder if something like this would work: http://openhatch.org/search/?q=toughness=bitesizelanguage=Python It looks like they can suck in appropriately flagged BZ issues. -Rob It would need new tools since BugZilla does not offer an adequate interface and lacks the individual part (i.e., a self-assessed list of skills that will match the tasks). If somebody wants to draft some ideas on a wiki page, this is something that might be worth some effort on a medium term. Regards, Andrea.
Re: [question] build infra structure.
Thanks for offering your help, I will definitively come back to that. Just one question, is there a design document or something where I can read how the new makefile concept is going to work ? Jan. On 2 November 2012 09:26, Andre Fischer awf@gmail.com wrote: On 01.11.2012 18:31, jan iversen wrote: you See below please. On 1 November 2012 18:18, Andre Fischer awf@gmail.com wrote: On 01.11.2012 17:57, jan iversen wrote: See below please. THANKS for your VERY informative answer, it helped me a lot. I was of the simple idea, that we pursued a simple build process made up of gnuMake and an addon to gather for the shortcoming of gnumake in respect of cascaded makefiles. We are in the process of migrating from dmake to GNU make. When that is finished then we will have essentially one single makefile. Well, there will be one top level makefile that includes all the other makefiles. But there will not one make process that starts other makes in subprocesses. That would be evil, or so I have been told, see http://wiki.openoffice.org/wiki/Build_System_Analysishttp://wiki.openoffice.org/**wiki/Build_System_Analysis htt**p://wiki.openoffice.org/wiki/**Build_System_Analysishttp://wiki.openoffice.org/wiki/Build_System_Analysis I am in the process of changing the l10n process. Currently it runs on one makefile that searches all directories, I want to change that to a target in every local makefile (build.lst). I am aware of that and am glad that you follow this approach. I am convinced that among a lot of other improvements, we could make the localization process a lot faster by a) using make (dmake or GNU make) for controlling what to do when and b) by integrating it into the build process to update the pootle data from time to time. Can I attach myself to your progress, or would you suggest that I attach my development to the current build process. my timeline is somewhat around new year. Conversion of Apache OpenOffice from dmake to gbuild is going very slow at the moment. I am afraid that you will have work with the current build process. But I am willing to help. I hope to see your presentation on video later, due to personal budget restriction (dont we all have that) I cannot participate. Sorry to hear that, I would have liked to meet you. Well if you come to FOSDEM, we can have a long chat. My problem is that I am currently only a contributor so that ticket alone is 600,- EUR. Yeah, I know what you mean. And I will think about FOSDEM. I am also prepared for google/skype videochats. That is good to know. Maybe after ApacheCon. -Andre
Re: extensions and translations.
+1 to your ideas, much better formulated than mine. see below for comments. Jan On 2 November 2012 12:09, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 11/01/2012 10:07 PM, schrieb jan iversen: Can standard loosely be defined as an extension: - is developed by people who have signed ICLA - uses the apache license header in the source files It's indeed important but IMHO this shouldn't be part of the decision to draw the standard as it's about formal and general things. - is of interest to the general public in different countries Absolute. - is willing to let the source be controlled/reviewed by committer. With the possibility to become a committer later-on. - accept a vote by the committers to be accepted If a code grant is necessary depends maybe a bit on the amount of the extension source code. +1, but having the option of a vote is not bad...I did not want to write accept that a committer can veto the change. If those points are fuillfilled we could add the project to swext, and then it would automatically be integrated in the build and l10n process. Is swext only for extension around AOO Writer or general? If for Writer then it should be located in a different, own directory within the source code. At least Wiki publisher attaches only to writer. What do you mean within the source code, is main/swext not within ? Please help me out here, I am not sure if that is enough for the apache way. I would suggest to define the standard around some factors. Some thoughts: - What is the benefit for AOO? This might be a bit problematic, who is to judge it. - Is this helful for the general public or only for specific users? +1 - Does it exchange existing functionality with something own? +1 - What are the usage numbers / review comments look like? If I understand it correct, you see the extension first in the usual extensions place, and then it can grow into AOO ? Would there not be cases, where it was developed directly within AOO. - How big is the extension (keep in mind we shouldn't blow-up our software too excessive). Is that not more a problem of release packaging ? We could put the extensions in an own installation, like language packs. - Don't install the extension by default but let the user decide what they want, then make 1-3 wizard pages in the installer only for installing extensions +1 Of course this can only work if the extension developer is willing to come into the AOO project with all the things needed (source grant, signed ICLA, header change, voting for releases, etc.). +1 that is important, extensions integrated in the source must obey the same rules as all other source code. Marcus On 1 November 2012 21:24, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 11/01/2012 01:17 PM, schrieb Rob Weir: On Thu, Nov 1, 2012 at 3:52 AM, Jürgen Schmidtjogischm...@gmail.com wrote: On 11/1/12 12:39 AM, Marcus (OOo) wrote: Am 10/27/2012 01:17 AM, schrieb jan iversen: I see, I have to get used to this license issues (a long time ago I believed open source was just open source, then I joined an apache project). never mind. Would it be to our advantage if we offered third party developers (that is how I see extension developers) the possibility to register a language file and get it translated as part of the language packs ? Of course it would be to our advantage; or let's say for the project and software. A lot of extensions would be available in many languages. However, I don't know where we should draw the line to set a limit. When we select here and there some extensions, then the other developers will ask why not their extensions. It's quite simple I would say, if people want develop extensions under ALv2 and want to contribute the code to the project. We can easy create a special section in our repo where we can host them. But this means they have to be handled in the same way as all other stuff here. Means a new release have to be voted... +1 I think the important thing is this: We don't just want code. We want communities. So if an extension author thinks that their extension is generally useful and he/she wants to join the AOO community and work on the extension here, and allow others to work on it as well, then this is good. Of course, +1. We can have a set of standard extensions. So, we just need to define the standard. Marcus And IMHO it's not possible to translate all strings for all extensions. But maybe others here have a great idea? we can't probably provide it and I think we have to do enough ;-). But I can think of an alternative service hosted somewhere else. Juergen Or should we just say extension developers does not concern us (and help AOO get more used) so we just look the other way ? Maybe the right way is somewhere in the middle. Yeah, maybe. ;-) Marcus On 27 October 2012 00:58, Marcus
Re: Encouraging participation
On 2 November 2012 17:54, Andrea Pescetti pesce...@apache.org wrote: On 01/11/2012 Rob Weir wrote: On Thu, Nov 1, 2012 at 4:21 PM, jan iversen wrote: - We need to focus more on people who want to help, instead of using all the legal stuff (which are necessary) as a buffer not to move things. (e.g. I got 2 volunteers working on a danish translation, highly motivated, now we are discussing details about how to release the stuff). ... I don't think anyone is using legal stuff' to prevent things from moving forward. There is a bit of confusion here. One thing is allowing volunteers to have feedback on their work, the other one is releasing their work. For feedback we needn't focus on legal issues. So the Danish translation as discussed in https://issues.apache.org/ooo/**show_bug.cgi?id=121179https://issues.apache.org/ooo/show_bug.cgi?id=121179 will be integrated in any next 3.4.x (informal, i.e., snapshots) builds. The legal stuff is not playing any roles here. But it is certainly true that a new volunteer is encouraged the best when they can contribute today and see their results released tomorrow. I'd focus on used rather than released: it is more motivating to see their results used (i.e., a snapshot build) soon than to see them released after months. And this is where we should improve. To give volunteers feedback we only need a very lightweight process, ideally zero. What is delaying us with the current translations, for example, is just that we need to determine a suitable deadline for translators to check in their PO files, integrating them on http://svn.apache.org/viewvc/** incubator/ooo/branches/AOO34/http://svn.apache.org/viewvc/incubator/ooo/branches/AOO34/and building snapshot for AOO34. At the moment this is indeed quite demanding on Juergen and Ariel. - I think events like ApacheCon is nice, but events like FOSDEM is quite a lot more important for the ordinary openSource developer. And we are planning a dev room at Fosdem for that reason. By FOSDEM (and ideally much earlier) we must be ready to integrate new volunteers in a way that fully satisfies them and the project. This is a priority for OpenOffice as a project. We are getting close to this for what concerns localization: I expect that in a couple weeks we will be able to involve, engage and satisfy localization volunteers with an established process. We must then do the same for QA, development, Marketing... An important result we should achieve is that nobody should feel frustrated by not having committer privileges: it is also up to us to define tasks that can be done without depending too much on a committer helping the contributor. At least we should warn them: if someone wants to rebuild an entire section of the OpenOffice website, like it is happening with Jan, he should be told in advance that this contribution is really welcome (and that, for most sections, we really need it!) but that at a certain point he might feel frustration for not being a committer. There are hundreds of tasks that can be done by non-committers, and we should keep the distinction clear when we advertise tasks for volunteers. (That said, the privileges of being a committer or a PMC member are greatly exaggerated at times... it's not that much really; but when this is the only obstacle to getting things really done, I can understand the impatience). I think I got ample warning ahead of doing the rewrite of l10n, what surprised was the discussion going on right now, that is quite frustrating, especially because I opened the theme before I did the work, and nobody complained, on the contrary many said yes please do. If you things like I do it can be quite frustrating not to have committer status, not at all for the privilege, but because I have to waster a committers valuable time, doing simple jobs. So the sentence it's not that much really, is not quite correct, it can be quite time saving. Regards, Andrea.
Re: Encouraging participation
On 2 November 2012 22:31, Dave Fisher dave2w...@comcast.net wrote: On Nov 2, 2012, at 2:12 PM, jan iversen wrote: On 2 November 2012 17:54, Andrea Pescetti pesce...@apache.org wrote: On 01/11/2012 Rob Weir wrote: On Thu, Nov 1, 2012 at 4:21 PM, jan iversen wrote: - We need to focus more on people who want to help, instead of using all the legal stuff (which are necessary) as a buffer not to move things. (e.g. I got 2 volunteers working on a danish translation, highly motivated, now we are discussing details about how to release the stuff). ... I don't think anyone is using legal stuff' to prevent things from moving forward. There is a bit of confusion here. One thing is allowing volunteers to have feedback on their work, the other one is releasing their work. For feedback we needn't focus on legal issues. So the Danish translation as discussed in https://issues.apache.org/ooo/**show_bug.cgi?id=121179 https://issues.apache.org/ooo/show_bug.cgi?id=121179 will be integrated in any next 3.4.x (informal, i.e., snapshots) builds. The legal stuff is not playing any roles here. But it is certainly true that a new volunteer is encouraged the best when they can contribute today and see their results released tomorrow. I'd focus on used rather than released: it is more motivating to see their results used (i.e., a snapshot build) soon than to see them released after months. And this is where we should improve. To give volunteers feedback we only need a very lightweight process, ideally zero. What is delaying us with the current translations, for example, is just that we need to determine a suitable deadline for translators to check in their PO files, integrating them on http://svn.apache.org/viewvc/** incubator/ooo/branches/AOO34/ http://svn.apache.org/viewvc/incubator/ooo/branches/AOO34/and building snapshot for AOO34. At the moment this is indeed quite demanding on Juergen and Ariel. - I think events like ApacheCon is nice, but events like FOSDEM is quite a lot more important for the ordinary openSource developer. And we are planning a dev room at Fosdem for that reason. By FOSDEM (and ideally much earlier) we must be ready to integrate new volunteers in a way that fully satisfies them and the project. This is a priority for OpenOffice as a project. We are getting close to this for what concerns localization: I expect that in a couple weeks we will be able to involve, engage and satisfy localization volunteers with an established process. We must then do the same for QA, development, Marketing... An important result we should achieve is that nobody should feel frustrated by not having committer privileges: it is also up to us to define tasks that can be done without depending too much on a committer helping the contributor. At least we should warn them: if someone wants to rebuild an entire section of the OpenOffice website, like it is happening with Jan, he should be told in advance that this contribution is really welcome (and that, for most sections, we really need it!) but that at a certain point he might feel frustration for not being a committer. There are hundreds of tasks that can be done by non-committers, and we should keep the distinction clear when we advertise tasks for volunteers. (That said, the privileges of being a committer or a PMC member are greatly exaggerated at times... it's not that much really; but when this is the only obstacle to getting things really done, I can understand the impatience). I think I got ample warning ahead of doing the rewrite of l10n, what surprised was the discussion going on right now, that is quite frustrating, especially because I opened the theme before I did the work, and nobody complained, on the contrary many said yes please do. If you things like I do it can be quite frustrating not to have committer status, not at all for the privilege, but because I have to waster a committers valuable time, doing simple jobs. You are not wasting a committers valuable time. The committer's time is spent evaluating your contribution. When the committer(s) begin to feel that their time is beginning to be wasted that is the point they ought to suggest to the PMC that it is time DISCUSS giving the individual committers rights. This discussion occurs in private, the discussion is then followed by a private VOTE that lasts at least 3 days. EIther or both of these processes can be public on the dev list. I think I formulated myself badly, there is a process for being invited to be committer and I have NO opinion on that process, except it sounds reasonable to me !! The part about time waste (regarding the l10n website), is currently a discussion on l10n, so we should not also discuss it here. If the community thinks that a private DISCUSS followed by a public VOTE would encourage
Re: CMS diff:
Thanks. On 2 November 2012 23:36, Kay Schenk kay.sch...@gmail.com wrote: Hi Jan-- This change in now in production. On 11/02/2012 01:33 AM, jan iversen wrote: Clone URL (Committers only): https://cms.apache.org/**redirect?new=anonymous;action=** diff;uri=http://ooo-site.**apache.org/l10n-new%2Ftopnav.**mdtexthttps://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://ooo-site.apache.org/l10n-new%2Ftopnav.mdtext jan iversen Index: trunk/content/l10n-new/topnav.**mdtext ==**==**=== --- trunk/content/l10n-new/topnav.**mdtext(revision 1404890) +++ trunk/content/l10n-new/topnav.**mdtext(working copy) @@ -8,4 +8,4 @@ [m0]: /l10n-new/documentation.html L10n documentation [m1]: /l10n-new/support.htmlLocalization support [m2]: /l10n-new/team.html Apache OpenOffice in your Native Language -[m3]: /l10n-new/archive/index.html Old site + -- --**--** MzK Anyone who considers protocol unimportant has never dealt with a cat. -- Robert Heinlein
Re: [DOCUMENTATION]Wrong use of scientific notation
May I politely as a mathematician point out that there is a major difference in the 2 proposals. Number 1 is a mathematical expression whereas number 2 is a number. Now I do not know where it is used, but if I copy both suggestions into Calc, it believes it is text. Should we not have a format that our own calc accept as a number ?? I agree with andrea that number 2 is more readable (and then forget it is not a number). rgds Jan I. On 3 November 2012 17:47, Andrea Pescetti pesce...@apache.org wrote: RGB ES wrote: On the help files, you find numbers written like 1.79769313486232 x 10E308 This is wrong: it should be either 1.79769313486232 x 10^308 or 1.79769313486232E308 what do you think? Yes, it's wrong and your first proposal is correct and more readable than the second one. Then I wonder how many times we have these kind of numbers in our documentation... and probably when they do appear we are more interested in their order of magnitude than in their actual value. Regards, Andrea.
Re: [DOCUMENTATION]Wrong use of scientific notation
ups, our calc does not like . if it is setup for e.g. en-GB, so actually calc accepted the second notation if I changed it to , Would it be possible to have a macro or something for . so it appears in , for me . signals 1000 (1.000) Jan. On 3 November 2012 18:29, Dennis E. Hamilton dennis.hamil...@acm.orgwrote: It appears that all three forms are correct as notations for the same numerical value where . is recognized as a decimal point. I agree that there should be consistency. I think context of the numeral is important. In particular, which is most likely to be easily recognized and understood by the intended reader of the particular information? Is there something about the form chosen that is relevant to the context in which it occurs. Off hand, 1.79769313486232E+308 (my preference) is related to the expression of numerical constant values in input-output of data and in programming languages. The common formula presentation, using mathematical notation, is more like 1.79769313486232 x 10^308, namely 1.79769313486232⨯10⁵⁸ (The above example depends on having a good Unicode font.) (I couldn't find a good superscript 3 so I changed the exponent in the Unicoded example). It should not be difficult to use correct symbols and superscripts in the documentation. - Dennis -Original Message- From: RGB ES [mailto:rgb.m...@gmail.com] Sent: Saturday, November 03, 2012 07:21 To: ooo-dev@incubator.apache.org Subject: [DOCUMENTATION]Wrong use of scientific notation On the help files, you find numbers written like 1.79769313486232 x 10E308 This is wrong: it should be either 1.79769313486232 x 10^308 or 1.79769313486232E308 what do you think? Regards Ricardo
Re: [DOCUMENTATION]Wrong use of scientific notation
When it is in the part that is being translated localizers will take care of , versus .. I know the x10 is a scientific notation and I use it and like it, but since our calc does not accept it, I would prefer the E notation, so people does not get confused. Jan. On 3 November 2012 19:14, RGB ES rgb.m...@gmail.com wrote: 2012/11/3 jan iversen jancasacon...@gmail.com May I politely as a mathematician point out that there is a major difference in the 2 proposals. Number 1 is a mathematical expression whereas number 2 is a number. I'm physicist :) The first number is the traditional scientific notation (specially if proper super indexes are used) while the second one is the E notation http://en.wikipedia.org/wiki/Scientific_notation#E_notation Now I do not know where it is used, One example https://translate.apache.org/es/OOo_34_help/translate.html?unit=6097629 Regards Ricardo but if I copy both suggestions into Calc, it believes it is text. Should we not have a format that our own calc accept as a number ?? I agree with andrea that number 2 is more readable (and then forget it is not a number). rgds Jan I. On 3 November 2012 17:47, Andrea Pescetti pesce...@apache.org wrote: RGB ES wrote: On the help files, you find numbers written like 1.79769313486232 x 10E308 This is wrong: it should be either 1.79769313486232 x 10^308 or 1.79769313486232E308 what do you think? Yes, it's wrong and your first proposal is correct and more readable than the second one. Then I wonder how many times we have these kind of numbers in our documentation... and probably when they do appear we are more interested in their order of magnitude than in their actual value. Regards, Andrea.
