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.
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: 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
Re: [RELEASE] Releasing new languages for 3.4.1
I do not understand the release discussion assuming juergen is right. why don't we ask each team to send a mail confirming they have made QA then we would release the language packs officially (at least this time) this would also give us time to discuss the ideal situation. juergen: you will (hopefully) soon get an extra pair of hands to help! Den 31/10/2012 11.10 skrev Jürgen Schmidt jogischm...@gmail.com: On 10/30/12 4:22 PM, jan iversen wrote: Question: Is there a rule in the apache way defining who can do QA, or is it totally up to the single teams ? It's up to the teams I think Do we use the review statistic in pootle to anything, it seems actually quite clever. we don't make use of it right now and I have to confess that I haven't really looked in it yet because of the lack of time. Juergen Jan. On 30 October 2012 16:17, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/30/12 2:46 PM, Rob Weir wrote: On Oct 30, 2012, at 9:03 AM, RGB ES rgb.m...@gmail.com wrote: 2012/10/30 Jürgen Schmidt jogischm...@gmail.com On 10/27/12 3:57 AM, Rob Weir wrote: On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir robw...@apache.org wrote: On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: ... it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). It is an interesting question if we should only vote for source releases. Certainly these are the only official release. I think that the practice is to vote for binary packages as well. Clearly those have a different bar. It is worth discussing, but I am inclined to think that we do need to VOTE on these packages, but in this case we are voting at a certain level of trust for the packager and translations. But the point is we need to release the source that the binaries depend on, where that source is from this project. It would be one thing if we were just releasing a new platform port of existing source packages. But we're not. We're talking about new translations resources, where such resources are in SVN and are required as part of the build process in order to build the localized binaries. No downstream consumer of the source will be able to build these localizations without having access to the translated resources. Therefore these resources should be reviewed, voted on and released. Remember, the translations are non-trivial creative works, translations of not only UI strings, but larger text passages from the help files. They are under copyright and made available under license. So we need to do our due diligence via the release process before we distribute such materials. Should say, before we distribute such materials in source OR source and binary form. The issues are the same. Remember, the source package is canonical. I'm surprised to hear talk now of releasing only binaries. I am still not sure how we can address this but I would really like to make new translations available as soon as possible. What about the idea to prepare official developer language packs based on the AOO34 branch and where the new translations are already checked in? If we decided later to release a 3.4.2 because of other critical security or general bugfixes the new translations becomes included automatically. The new language packs will have the same version number 3.4.1 but are not officially released and are available via the snapshot page. When we reach a state where we have release build bots, we can probably trigger much easier a complete respin with the same product version but based on a new revision number including the new translations. Juergen +1. I like the idea. We can put on the download page a link to additional untested language packs and add these language packs are being prepared for the next AOO version, but you can use them right now or something like that. Even beta releases are still releases from the Apache perspective and still require that we go through a release vote. Why are we trying so hard to avoid this process? It isn't that hard. And it is important that we follow the procedures before putting the Apache label on software we make available to the public. I don't see that we try to avoid this process. But with with a certain level of QA we have to test the new language builds anyway. Means in detail we can start with the snapshot builds and can test it. If we get no complains we can create a new src release (a respin if possible) where the new translations are included. And we upload only the new src release and the new language packs. I would be also fine with uploading full install sets but this is matter of taste and space. Juergen
Re: [RELEASE] Releasing new languages for 3.4.1
Ok, I thought team meant language teams. But I have searched the Wiki and cannot find any documentation on the required QA procedure relating to national languages. Can it be, that it was never really defined and written down ?? For code, there seems to be guidelines, but also no real definition of how much test need to be done (it is pretty well defined what happens when QA finds a problem in a release candidate). For the future, not for the set of languages, it would be a good idea to have a clear definition of - which QA gates has to be passed - who (roles) defines if a gate if full filled (national team, someone else?) Jan. On 31 October 2012 14:42, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/31/12 12:18 PM, jan iversen wrote: I do not understand the release discussion assuming juergen is right. or I have misunderstand your question ;-) I think we as AOO can define how we do QQ and how we want to ensure the quality of our releases. Besides the functional aspects here we have to follow some Apache rules how releases have to be made. Juergen why don't we ask each team to send a mail confirming they have made QA then we would release the language packs officially (at least this time) this would also give us time to discuss the ideal situation. juergen: you will (hopefully) soon get an extra pair of hands to help! Den 31/10/2012 11.10 skrev Jürgen Schmidt jogischm...@gmail.com: On 10/30/12 4:22 PM, jan iversen wrote: Question: Is there a rule in the apache way defining who can do QA, or is it totally up to the single teams ? It's up to the teams I think Do we use the review statistic in pootle to anything, it seems actually quite clever. we don't make use of it right now and I have to confess that I haven't really looked in it yet because of the lack of time. Juergen Jan. On 30 October 2012 16:17, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/30/12 2:46 PM, Rob Weir wrote: On Oct 30, 2012, at 9:03 AM, RGB ES rgb.m...@gmail.com wrote: 2012/10/30 Jürgen Schmidt jogischm...@gmail.com On 10/27/12 3:57 AM, Rob Weir wrote: On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir robw...@apache.org wrote: On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: ... it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). It is an interesting question if we should only vote for source releases. Certainly these are the only official release. I think that the practice is to vote for binary packages as well. Clearly those have a different bar. It is worth discussing, but I am inclined to think that we do need to VOTE on these packages, but in this case we are voting at a certain level of trust for the packager and translations. But the point is we need to release the source that the binaries depend on, where that source is from this project. It would be one thing if we were just releasing a new platform port of existing source packages. But we're not. We're talking about new translations resources, where such resources are in SVN and are required as part of the build process in order to build the localized binaries. No downstream consumer of the source will be able to build these localizations without having access to the translated resources. Therefore these resources should be reviewed, voted on and released. Remember, the translations are non-trivial creative works, translations of not only UI strings, but larger text passages from the help files. They are under copyright and made available under license. So we need to do our due diligence via the release process before we distribute such materials. Should say, before we distribute such materials in source OR source and binary form. The issues are the same. Remember, the source package is canonical. I'm surprised to hear talk now of releasing only binaries. I am still not sure how we can address this but I would really like to make new translations available as soon as possible. What about the idea to prepare official developer language packs based on the AOO34 branch and where the new translations are already checked in? If we decided later to release a 3.4.2 because of other critical security or general bugfixes the new translations becomes included automatically. The new language packs will have the same version number 3.4.1 but are not officially released and are available via the snapshot page. When we reach a state where we have release build bots, we can probably trigger much easier a complete respin with the same product version but based on a new revision number including the new translations. Juergen +1. I like the idea
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: proposal for new l10n workflow
I just double checked: the pointer is: Localization AOOhttp://wiki.openoffice.org/wiki/Localization_AOO, which clearly stated (the very first lines of the document) This document is based on and extents Localization_for_developershttp://wiki.openoffice.org/wiki/Localization_for_developers. The document is work in progress showing the result of a detailed technical analysis of the current process (version 3.4.1) . As such this document should be seen as a replacement of Localization_for_developershttp://wiki.openoffice.org/wiki/Localization_for_developers . But I will happely remove it if you prefer, but then where do I put a link to the more detailed description of the CURRENT process. jan. On 30 October 2012 13:30, jan iversen jancasacon...@gmail.com wrote: I am guilty. see below. On 30 October 2012 13:22, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/27/12 10:51 PM, jan iversen wrote: Based on the comments I have received, I have updated the document. The major changes are: - removed l10n web page tools - no auto-commit in any tools - proposed changes to pootle server (based on request from andrea, to use/change existing tools) - added more text on the translation workflow, inkl. local teams The document is available as pdf: http://wiki.openoffice.org/wiki/File:L10procNew2.pdf and (due to a polite hint) as a wiki page: http://wiki.openoffice.org/wiki/Localization_AOO/new_proposal Furthermore a projectplan is available as a wiki page: http://wiki.openoffice.org/wiki/Localization_AOO/workPlan this mail is posted on both ooo-L10n and ooo-dev, but please use ooo-dev for discussions. I noticed that somebody put an outdated template on http://wiki.openoffice.org/wiki/Localization_for_developers which I think is a little bit early. The new page is a great resource to discuss a new workflow and necessary improvements. But the currently Localization for developers page describes how it works today. The page it points to, is NOT the new proposal, that would be wrong, but the first I made with a more detailed description of how it works today. I hope that is ok ? We should avoid confusion here, the new process is under development yet but not available yet. I totally agree, and I have not made links that suggest otherwise. Juergen Andrea: I hope you have time to see if your suggestions are well represented now, so this document could be used as discussion basis when you meet the pootle people. Have a nice evening. jan I.
Re: [RELEASE] Releasing new languages for 3.4.1
+1, such a download page additional untested language packs would allow us to make a translation official immediately with a limited responsibility, just like the snapshots. jan On 30 October 2012 14:02, RGB ES rgb.m...@gmail.com wrote: 2012/10/30 Jürgen Schmidt jogischm...@gmail.com On 10/27/12 3:57 AM, Rob Weir wrote: On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir robw...@apache.org wrote: On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: ... it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). It is an interesting question if we should only vote for source releases. Certainly these are the only official release. I think that the practice is to vote for binary packages as well. Clearly those have a different bar. It is worth discussing, but I am inclined to think that we do need to VOTE on these packages, but in this case we are voting at a certain level of trust for the packager and translations. But the point is we need to release the source that the binaries depend on, where that source is from this project. It would be one thing if we were just releasing a new platform port of existing source packages. But we're not. We're talking about new translations resources, where such resources are in SVN and are required as part of the build process in order to build the localized binaries. No downstream consumer of the source will be able to build these localizations without having access to the translated resources. Therefore these resources should be reviewed, voted on and released. Remember, the translations are non-trivial creative works, translations of not only UI strings, but larger text passages from the help files. They are under copyright and made available under license. So we need to do our due diligence via the release process before we distribute such materials. Should say, before we distribute such materials in source OR source and binary form. The issues are the same. Remember, the source package is canonical. I'm surprised to hear talk now of releasing only binaries. I am still not sure how we can address this but I would really like to make new translations available as soon as possible. What about the idea to prepare official developer language packs based on the AOO34 branch and where the new translations are already checked in? If we decided later to release a 3.4.2 because of other critical security or general bugfixes the new translations becomes included automatically. The new language packs will have the same version number 3.4.1 but are not officially released and are available via the snapshot page. When we reach a state where we have release build bots, we can probably trigger much easier a complete respin with the same product version but based on a new revision number including the new translations. Juergen +1. I like the idea. We can put on the download page a link to additional untested language packs and add these language packs are being prepared for the next AOO version, but you can use them right now or something like that. Regards Ricardo -Rob -Rob Regards, Dave
Re: proposal for new l10n workflow
If my page needs updating, feel free to do so, I actually copied all the scripts things from the other page. jan. On 30 October 2012 14:28, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/30/12 1:33 PM, jan iversen wrote: I just double checked: the pointer is: Localization AOOhttp://wiki.openoffice.org/wiki/Localization_AOO, which clearly stated (the very first lines of the document) This document is based on and extents Localization_for_developers http://wiki.openoffice.org/wiki/Localization_for_developers. The document is work in progress showing the result of a detailed technical analysis of the current process (version 3.4.1) . As such this document should be seen as a replacement of Localization_for_developers http://wiki.openoffice.org/wiki/Localization_for_developers . I simply missed some basic info how the tools have to be used etc.. I was confused... But I will happely remove it if you prefer, but then where do I put a link to the more detailed description of the CURRENT process. no need to remove it now, I know whats behind and as long as nobody delete it I am fine Juergen jan. On 30 October 2012 13:30, jan iversen jancasacon...@gmail.com wrote: I am guilty. see below. On 30 October 2012 13:22, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/27/12 10:51 PM, jan iversen wrote: Based on the comments I have received, I have updated the document. The major changes are: - removed l10n web page tools - no auto-commit in any tools - proposed changes to pootle server (based on request from andrea, to use/change existing tools) - added more text on the translation workflow, inkl. local teams The document is available as pdf: http://wiki.openoffice.org/wiki/File:L10procNew2.pdf and (due to a polite hint) as a wiki page: http://wiki.openoffice.org/wiki/Localization_AOO/new_proposal Furthermore a projectplan is available as a wiki page: http://wiki.openoffice.org/wiki/Localization_AOO/workPlan this mail is posted on both ooo-L10n and ooo-dev, but please use ooo-dev for discussions. I noticed that somebody put an outdated template on http://wiki.openoffice.org/wiki/Localization_for_developers which I think is a little bit early. The new page is a great resource to discuss a new workflow and necessary improvements. But the currently Localization for developers page describes how it works today. The page it points to, is NOT the new proposal, that would be wrong, but the first I made with a more detailed description of how it works today. I hope that is ok ? We should avoid confusion here, the new process is under development yet but not available yet. I totally agree, and I have not made links that suggest otherwise. Juergen Andrea: I hope you have time to see if your suggestions are well represented now, so this document could be used as discussion basis when you meet the pootle people. Have a nice evening. jan I.
Re: [RELEASE] Releasing new languages for 3.4.1
Question: Is there a rule in the apache way defining who can do QA, or is it totally up to the single teams ? Do we use the review statistic in pootle to anything, it seems actually quite clever. Jan. On 30 October 2012 16:17, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/30/12 2:46 PM, Rob Weir wrote: On Oct 30, 2012, at 9:03 AM, RGB ES rgb.m...@gmail.com wrote: 2012/10/30 Jürgen Schmidt jogischm...@gmail.com On 10/27/12 3:57 AM, Rob Weir wrote: On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir robw...@apache.org wrote: On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: ... it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). It is an interesting question if we should only vote for source releases. Certainly these are the only official release. I think that the practice is to vote for binary packages as well. Clearly those have a different bar. It is worth discussing, but I am inclined to think that we do need to VOTE on these packages, but in this case we are voting at a certain level of trust for the packager and translations. But the point is we need to release the source that the binaries depend on, where that source is from this project. It would be one thing if we were just releasing a new platform port of existing source packages. But we're not. We're talking about new translations resources, where such resources are in SVN and are required as part of the build process in order to build the localized binaries. No downstream consumer of the source will be able to build these localizations without having access to the translated resources. Therefore these resources should be reviewed, voted on and released. Remember, the translations are non-trivial creative works, translations of not only UI strings, but larger text passages from the help files. They are under copyright and made available under license. So we need to do our due diligence via the release process before we distribute such materials. Should say, before we distribute such materials in source OR source and binary form. The issues are the same. Remember, the source package is canonical. I'm surprised to hear talk now of releasing only binaries. I am still not sure how we can address this but I would really like to make new translations available as soon as possible. What about the idea to prepare official developer language packs based on the AOO34 branch and where the new translations are already checked in? If we decided later to release a 3.4.2 because of other critical security or general bugfixes the new translations becomes included automatically. The new language packs will have the same version number 3.4.1 but are not officially released and are available via the snapshot page. When we reach a state where we have release build bots, we can probably trigger much easier a complete respin with the same product version but based on a new revision number including the new translations. Juergen +1. I like the idea. We can put on the download page a link to additional untested language packs and add these language packs are being prepared for the next AOO version, but you can use them right now or something like that. Even beta releases are still releases from the Apache perspective and still require that we go through a release vote. Why are we trying so hard to avoid this process? It isn't that hard. And it is important that we follow the procedures before putting the Apache label on software we make available to the public. I don't see that we try to avoid this process. But with with a certain level of QA we have to test the new language builds anyway. Means in detail we can start with the snapshot builds and can test it. If we get no complains we can create a new src release (a respin if possible) where the new translations are included. And we upload only the new src release and the new language packs. I would be also fine with uploading full install sets but this is matter of taste and space. Juergen -Rob Regards Ricardo -Rob -Rob Regards, Dave
Re: [RELEASE] Releasing new languages for 3.4.1
Hi Speaking for myself and the other 2 in the teamwe do the translation to get AOO available in denmark (again). Right now another openSource product is using the fact that we cannot release our versions in danish, to their benefit. I do not want to compete (which is why I do not write the name, we all know), but also I want to make that AOO is THE well established, well tested, high quality free Software that the companies want to use. So internal things are handy, when it comes to testing, but not when it comes to showing a danish user commity that we are still alive and kicking. jan. On 30 October 2012 16:48, Rob Weir robw...@apache.org wrote: On Tue, Oct 30, 2012 at 11:17 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/30/12 2:46 PM, Rob Weir wrote: On Oct 30, 2012, at 9:03 AM, RGB ES rgb.m...@gmail.com wrote: 2012/10/30 Jürgen Schmidt jogischm...@gmail.com On 10/27/12 3:57 AM, Rob Weir wrote: On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir robw...@apache.org wrote: On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: ... it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). It is an interesting question if we should only vote for source releases. Certainly these are the only official release. I think that the practice is to vote for binary packages as well. Clearly those have a different bar. It is worth discussing, but I am inclined to think that we do need to VOTE on these packages, but in this case we are voting at a certain level of trust for the packager and translations. But the point is we need to release the source that the binaries depend on, where that source is from this project. It would be one thing if we were just releasing a new platform port of existing source packages. But we're not. We're talking about new translations resources, where such resources are in SVN and are required as part of the build process in order to build the localized binaries. No downstream consumer of the source will be able to build these localizations without having access to the translated resources. Therefore these resources should be reviewed, voted on and released. Remember, the translations are non-trivial creative works, translations of not only UI strings, but larger text passages from the help files. They are under copyright and made available under license. So we need to do our due diligence via the release process before we distribute such materials. Should say, before we distribute such materials in source OR source and binary form. The issues are the same. Remember, the source package is canonical. I'm surprised to hear talk now of releasing only binaries. I am still not sure how we can address this but I would really like to make new translations available as soon as possible. What about the idea to prepare official developer language packs based on the AOO34 branch and where the new translations are already checked in? If we decided later to release a 3.4.2 because of other critical security or general bugfixes the new translations becomes included automatically. The new language packs will have the same version number 3.4.1 but are not officially released and are available via the snapshot page. When we reach a state where we have release build bots, we can probably trigger much easier a complete respin with the same product version but based on a new revision number including the new translations. Juergen +1. I like the idea. We can put on the download page a link to additional untested language packs and add these language packs are being prepared for the next AOO version, but you can use them right now or something like that. Even beta releases are still releases from the Apache perspective and still require that we go through a release vote. Why are we trying so hard to avoid this process? It isn't that hard. And it is important that we follow the procedures before putting the Apache label on software we make available to the public. I don't see that we try to avoid this process. But with with a certain level of QA we have to test the new language builds anyway. Means in detail we can start with the snapshot builds and can test it. If we get no complains we can create a new src release (a respin if possible) where the new translations are included. And we upload only the new src release and the new language packs. I would be also fine with uploading full install sets but this is matter of taste and space. It may be worth reviewing this section on test packages versus releases: http://www.apache.org/dev/release.html#release-types It is possible to have something less than a release. We do that, for
Re: AOO volunteers: essential skills and tasks
I think asking me would be wrong...I would come with the much to complicated answers :-) I really like the idea of simple start page, for people who want to help without getting so deeply involved as I am trying to become. May I suggest a wiki page, where we constantly (very frequently write) - these items needs to be translated to (languages missing) - these items (e.g. user doc) needs to be enhanced updated. - and something like, feel free to start with any of these items, that would really help AOO. People like myself, is partly beyond help, meaning the best way to help us, is for someone to be a mentor. Above a given level it becomes too difficult to write documentaion and much easier to have a mentor (which would save this list for a lot of noise, for which I apologize). jan. On 29 October 2012 05:14, Louis Suárez-Potts lui...@gmail.com wrote: On 12-10-28, at 19:30 , Rob Weir robw...@apache.org 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. I agree. One thing that worked sometimes at Ye Olde OpenOffice was simply to ask Jan and others what they would want there to make life easier for us all. This strategy has a couple of advantages. One is that by crowdsourcing it one can plausibly get answers that differ from the ones we, so familiar with this site and what we do would not come up with, and two, share the responsibility of improvement with the community affected. That latter is goodness. -louis
Re: extensions and translations.
Got it, as Marcus explained, this is not a path to follow, but now I can write in my document that is has been discussed. jan On 27 October 2012 14:47, Ariel Constenla-Haile arie...@apache.org wrote: On Sat, Oct 27, 2012 at 10:27:34AM +0200, jan iversen wrote: I agree with you, we should NOT put a new framework on extensions writer. I was thinking along the lines of make a new directory ./extras/extensions/source, with files extension name.known extension This will force the extension developer to release that file under the ALv2, because only ALv2 code can be committed. Regards -- Ariel Constenla-Haile La Plata, Argentina
Re: proposal for new l10n workflow
Based on the comments I have received, I have updated the document. The major changes are: - removed l10n web page tools - no auto-commit in any tools - proposed changes to pootle server (based on request from andrea, to use/change existing tools) - added more text on the translation workflow, inkl. local teams The document is available as pdf: http://wiki.openoffice.org/wiki/File:L10procNew2.pdf and (due to a polite hint) as a wiki page: http://wiki.openoffice.org/wiki/Localization_AOO/new_proposal Furthermore a projectplan is available as a wiki page: http://wiki.openoffice.org/wiki/Localization_AOO/workPlan this mail is posted on both ooo-L10n and ooo-dev, but please use ooo-dev for discussions. Andrea: I hope you have time to see if your suggestions are well represented now, so this document could be used as discussion basis when you meet the pootle people. Have a nice evening. jan I. On 25 October 2012 23:01, Andrea Pescetti pesce...@apache.org wrote: On 21/10/2012 jan iversen wrote: I have finally finished my proposal for a new workflow. please have a look at: http://wiki.openoffice.org/**wiki/File:L10procNew.pdfhttp://wiki.openoffice.org/wiki/File:L10procNew.pdf It seems I'm the first one who replies after having read your document in full. And the quality of your proposal is not the issue here: on the contrary, it is a very good one and I'm answering in detail below. So the issue must be somewhere else. I'm confident you will understand that I'm not criticizing or lecturing you here, and I'm not implying any of the items below to be you fault (none is); but maybe this will help you in getting better feedback in future. 1) Unfortunate timing. We've just graduated, the Apache Conference is coming in about one week, we need to relocate all infrastructure... It's a busy period, so we may be less responsive than usual. 2) Excess of communication. If all people on this list had written as much as you did in the last 24 hours to the OpenOffice lists, ooo-dev would have received a message every 9 seconds! If you make yourself manageable it will be easier for us to answer your requests with less confusion. 3) Dispersion of communication. Discussion about your proposal is scattered in three different threads across ooo-dev and ooo-l10n (not counting private e-mails); if you need to send a message to multiple lists, and this is a good example, it's best to send one message to two lists (and specify which one should receive answers) since answers will be grouped in the same discussion for people who are reading e-mail by discussions. 4) Proposal format. Uploading a PDF is very convenient but it does not make others feel empowered to really contribute. I would have applied a dozen typo fixes to your proposal if it had been available as a wiki page. Others might have done the same. OK, enough said. The proposal has significant merit, so let's focus on that for the rest of this message. It won't be short: it's still a 20-page document. The main reasons to drive it forward are: - It puts us back in total control of the l10n process, with no need to rely on partially broken or lost tools. - It reduces the number of steps strings must go through for being translated and imported back. - It automates a number of operations that have been manual so far. - It allows to have a proper version control for translations. In general, I think the document would benefit from some knowledge about how the process works with established teams: - There is a string freeze date in the release schedule (this concept needn't be taken away: for sure we still want a string freeze even if tools allow a continuous localization; translators shouldn't have the surprise to see new strings appear in the last weeks before a release) - After string freeze, strings are made available in Pootle (and this happens automatically in your proposal) - Volunteers pick a file, usually a help file and the main application related to it (so, the sw module for Writer and its help file; and, answering another message from you, the subdivision you propose would be OK). Here indeed it is helpful to know that a file has been taken, something that volunteers track manually at the moment. Volunteers do not have time constraints and may well take two weeks to complete their assignments: the 4 days you propose are not realistic for most teams. - Nobody works on Pootle. This has nothing to do with rights, it is totally incorrect to see Pootle as the committers tool. The Pootle server used to be slow and not responsive and anyway, as a matter of fact, most people, including me, prefer to work with downloaded files. - Volunteers mark all strings they touched as fuzzy to distinguish them; if I understand correctly, a XLIFF based workflow here would suggest to mark the strings as to be reviewed. - Other volunteers (in general one person per language) review the translations, collect all
Re: proposal for new l10n workflow
Thanks a lot for your long and informative answer, I read it with a positive attitude and will just make one comment, it is hard to be new especially with the state of documentation we have. I will in the future make a lot less noise. I will work your comments into my proposal, and in general I agree it is better to extend existing tools than to make new ones. There is however one misunderstanding (probably due to my formulations) that I need to correct, the l10n upload/download feature was NOT to circumvent the system, but to allow contributors to upload files without having to go through private mail adresses/bugzilla etc. Thanks for using time on my proposal. Jan. On 25 October 2012 23:01, Andrea Pescetti pesce...@apache.org wrote: On 21/10/2012 jan iversen wrote: I have finally finished my proposal for a new workflow. please have a look at: http://wiki.openoffice.org/**wiki/File:L10procNew.pdfhttp://wiki.openoffice.org/wiki/File:L10procNew.pdf It seems I'm the first one who replies after having read your document in full. And the quality of your proposal is not the issue here: on the contrary, it is a very good one and I'm answering in detail below. So the issue must be somewhere else. I'm confident you will understand that I'm not criticizing or lecturing you here, and I'm not implying any of the items below to be you fault (none is); but maybe this will help you in getting better feedback in future. 1) Unfortunate timing. We've just graduated, the Apache Conference is coming in about one week, we need to relocate all infrastructure... It's a busy period, so we may be less responsive than usual. 2) Excess of communication. If all people on this list had written as much as you did in the last 24 hours to the OpenOffice lists, ooo-dev would have received a message every 9 seconds! If you make yourself manageable it will be easier for us to answer your requests with less confusion. 3) Dispersion of communication. Discussion about your proposal is scattered in three different threads across ooo-dev and ooo-l10n (not counting private e-mails); if you need to send a message to multiple lists, and this is a good example, it's best to send one message to two lists (and specify which one should receive answers) since answers will be grouped in the same discussion for people who are reading e-mail by discussions. 4) Proposal format. Uploading a PDF is very convenient but it does not make others feel empowered to really contribute. I would have applied a dozen typo fixes to your proposal if it had been available as a wiki page. Others might have done the same. OK, enough said. The proposal has significant merit, so let's focus on that for the rest of this message. It won't be short: it's still a 20-page document. The main reasons to drive it forward are: - It puts us back in total control of the l10n process, with no need to rely on partially broken or lost tools. - It reduces the number of steps strings must go through for being translated and imported back. - It automates a number of operations that have been manual so far. - It allows to have a proper version control for translations. In general, I think the document would benefit from some knowledge about how the process works with established teams: - There is a string freeze date in the release schedule (this concept needn't be taken away: for sure we still want a string freeze even if tools allow a continuous localization; translators shouldn't have the surprise to see new strings appear in the last weeks before a release) - After string freeze, strings are made available in Pootle (and this happens automatically in your proposal) - Volunteers pick a file, usually a help file and the main application related to it (so, the sw module for Writer and its help file; and, answering another message from you, the subdivision you propose would be OK). Here indeed it is helpful to know that a file has been taken, something that volunteers track manually at the moment. Volunteers do not have time constraints and may well take two weeks to complete their assignments: the 4 days you propose are not realistic for most teams. - Nobody works on Pootle. This has nothing to do with rights, it is totally incorrect to see Pootle as the committers tool. The Pootle server used to be slow and not responsive and anyway, as a matter of fact, most people, including me, prefer to work with downloaded files. - Volunteers mark all strings they touched as fuzzy to distinguish them; if I understand correctly, a XLIFF based workflow here would suggest to mark the strings as to be reviewed. - Other volunteers (in general one person per language) review the translations, collect all files and make them available to developers (Bugzilla, personal web space, e-mail...) So we already have a (kind of) team coordinator who reviews the files and is a committer. Again: you can assume that we have a person per
Re: [proposal] Outdated articles in Wiki
Do you mean the outdated symbol, which should do just fine ??
Jan.
On 26 October 2012 17:18, Jürgen Schmidt jogischm...@gmail.com wrote:
On 10/25/12 9:19 PM, jan iversen wrote:
Maybe we could move them to an archive ??
I think we can find probably common consensus that we want to delete
pages to clean up this old stuff.
For example nobody needs today the old building guides. Let us focus on
the future and here I think less but correct and up-to-date information
is more.
When I remember correct there exist a template that could be used to
mark a page for deletion.
Simply put {{Delete}} on top of the page
Or we can create our own delete template with further instructions how
to proceed.
Administrator can for this from time to time and can delete stuff. Or we
can try to cleanup such pages via a wiki bot.
Juergen
jan
On 25 October 2012 21:12, Alexandro Colorado j...@oooes.org wrote:
Nobody want to delete information and wiki pages only admin can
actually delete pages. Even then there might be some rights about
ownership. Is like sourceforge dont delete inactive projects.
Still good conversation to debate.
On 10/25/12, jan iversen jancasacon...@gmail.com wrote:
To my knowledge, articles that are marked outdated with a reference to
a
newer article stays in Wiki.
Would it not be a good idea to remove such pages, in order not to
confuse
users ??
There are however no means, which I can find, to do that ?
Reason for my idea/question is that I am looking at localization
(l10n),
and there are a bit of old information.
Jan.
--
Alexandro Colorado
PPMC Apache OpenOffice
http://es.openoffice.org
Re: [proposal] Outdated articles in Wiki
So if an article is outdated, then it is ready for deletionor ???
Is it wise to have outdated articles alongside the correct/newer ones,
thinking of e.g. building instructions it would at least confuse me.
but I have no problem using {{Delete}} thanks for advicing me.
jan.
On 26 October 2012 19:03, Keith N. McKenna keith.mcke...@comcast.netwrote:
Jan;
No the outdated symbol is different. {{Delete}} Is a template that puts
the article in a special category to be deleted by an admin or by a bot.
Keith
jan iversen wrote:
Do you mean the outdated symbol, which should do just fine ??
Jan.
On 26 October 2012 17:18, Jürgen Schmidt jogischm...@gmail.com wrote:
On 10/25/12 9:19 PM, jan iversen wrote:
Maybe we could move them to an archive ??
I think we can find probably common consensus that we want to delete
pages to clean up this old stuff.
For example nobody needs today the old building guides. Let us focus on
the future and here I think less but correct and up-to-date information
is more.
When I remember correct there exist a template that could be used to
mark a page for deletion.
Simply put {{Delete}} on top of the page
Or we can create our own delete template with further instructions how
to proceed.
Administrator can for this from time to time and can delete stuff. Or we
can try to cleanup such pages via a wiki bot.
Juergen
jan
On 25 October 2012 21:12, Alexandro Colorado j...@oooes.org wrote:
Nobody want to delete information and wiki pages only admin can
actually delete pages. Even then there might be some rights about
ownership. Is like sourceforge dont delete inactive projects.
Still good conversation to debate.
On 10/25/12, jan iversen jancasacon...@gmail.com wrote:
To my knowledge, articles that are marked outdated with a reference to
a
newer article stays in Wiki.
Would it not be a good idea to remove such pages, in order not to
confuse
users ??
There are however no means, which I can find, to do that ?
Reason for my idea/question is that I am looking at localization
(l10n),
and there are a bit of old information.
Jan.
--
Alexandro Colorado
PPMC Apache OpenOffice
http://es.openoffice.org
Re: [RELEASE] Releasing new languages for 3.4.1
just two small comments. have a nice weekend. Jan. On 26 October 2012 19:43, Andrea Pescetti pesce...@apache.org wrote: Rob Weir wrote: 1) release new languages via lang packs only for now 2) release full installs, but for only these new languages I don't see a big difference between a langpack and a full install in this case, so I'd go for full installs, unless releasing langpacks helps in communicating that these are late additions and that full installs will come with the next release. Can we really skip the release process? PO files == source, right? Yes, not exactly but quite (PO files are not taken verbatim into source, but they are imported and influence resource files which are in the source tree). Maybe a question for legal-discuss if we're not certain. If in the end we have consensus on releasing new languages for 3.4.1 instead of making a new release, indeed we will ask. How do we want to handle this on an ongoing basis? New point release for every new language? Every 5 new languages? It is certainly good for volunteers to get the encouragement of a fast turnaround for their work. But this is the same for a C++ programmer. There are big differences here, that are also the reason for me to consider releasing these new languages as soon as possible: - A translation is often done by a team; if we can publish it immediately, the team can the be involved in other activities like revamping the N-L website, local promotion and so on; if we wait too much, we risk to have no volunteers for the following release. - Releasing a new language is totally risk-free: a new language can't break functionality in OpenOffice, while any feature could have bugs and needs more qualified testing. I do not agree to that statement for two reasons - a bad translations will influence the reputation of AOO in that language zone. - Wrong translation of e.g. accelerators, might not break the product technically speaking, but for sure the end-user will experience it as non-functioning. In the end, I wonder whether the best solution is to get into a steady release cycle of quarterly releases (every 3 or 4 months)? This could be a solution too. In this case we would have the problem of choosing what to translate (3.4 or 3.5? probably we would ask new volunteers to focus on strings that will be in the next release, even though they aren't frozen yet). - I think it would be nice to give translators an early start possibility, giving them a choice of working late after freeze or taking parts now with the risk that new messages are added. In my experience the risk for changed messages are relatively low. Regards, Andrea.
Re: [RELEASE]: new snapshot base don revision r1400866
Please allow a side-question. Can the UNO command also be used to identify where a string is used in the UI framework and not only the source code where it is programmed ? my problem is that I was told that it would be of high value to language QA if the system could provide screenshots showing where a string was used. But today I can relate a string to a source, and not to how I access/see it in a running AOO. I know I can build AOO to show the key identifiers which helps a lot, but it still does not help to find the string. Thanks for your help in advance. Jan. On 26 October 2012 21:16, Ariel Constenla-Haile arie...@apache.org wrote: Hi Ricardo, On Fri, Oct 26, 2012 at 08:24:26PM +0200, RGB ES wrote: On the forums we are testing the ES version and I have a doubt about non translated text on the UI: while there are some strings that comes from new code (new functions on Calc) there are other strings that are identical to the ones on 3.4.1... but on 3.5dev are not translated! For example, under Insertar (Insert) there is an entry Movie and Sound that it is not translated on 3.5 (on 3.4.1 says Vídeo y sonido). Is this something to worry about or it is better to wait until 3.5 is on Pootle and everything is correctly integrated? you can expect this with strings that are retrieved using the UNO command, the UNO command is what identifies every UI feature in the application framework; you can find them in the XML files that define menu bars and toolbars in the office installation, for example grep -r .uno:InsertAVMedia /opt/ openoffice.org/basis3.4/share/config/soffice.cfg/modules/ Labels for these commands are stored in configuration files. In this case, .uno:InsertAVMedia was moved to the right configuration place: * 3.4 branch, under Popups: http://opengrok.adfinis-sygroup.org/source/xref/aoo-AOO34/main/officecfg/registry/data/org/openoffice/Office/UI/GenericCommands.xcu#5352 * trunk under Commands: http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/officecfg/registry/data/org/openoffice/Office/UI/GenericCommands.xcu#3075 Strings that were moved to the right category will appear untranslated, because they are now in fact different strings. There were also several commands that had the same string but were placed in different configuration files, these were moved to GenericCommands.xcu, but you shouldn't note a difference here (only when translating: several duplicated strings will be removed in 3.5). So, yes, the Pootle server is in 3.4, the developer snapshots are in 3.5, you'll have to wait until Pootle gets in sync with trunk. Regards -- Ariel Constenla-Haile La Plata, Argentina
Re: [proposal] Outdated articles in Wiki
Thanks for clearing that up. I have just been searching for build
instructions (again), and in the search response I cannot see if an article
is outdated, so I had to open some before I got the correct one.
Would it be an idea (if possible) to have outdated as a category, and
extend the search to say with/without outdated, if possible that would work
fine for me since I would hit the recent one when searching.
regards
Jan.
On 26 October 2012 21:16, Keith N. McKenna keith.mcke...@comcast.netwrote:
Jan;
{{Documentation/Outdated}} and {{delete}} are two seperate entities.
Outdated merely says that some inormation is outdated and should be
revised. {{delete}} is a special case that marks a file for speedy deletion
by an wiki administrator.
At least with the user documentation we tend to add to the document for
newer versions of the software rather than get rid of it as there are still
people using older versions. This can however get carried to extremes. My
personal opinion is that it is probably time to start seriously
considering purging version 2.x stuff, but that is a discussion for another
thread.
Regards
Keith
jan iversen wrote:
So if an article is outdated, then it is ready for deletionor ???
Is it wise to have outdated articles alongside the correct/newer ones,
thinking of e.g. building instructions it would at least confuse me.
but I have no problem using {{Delete}} thanks for advicing me.
jan.
On 26 October 2012 19:03, Keith N. McKenna keith.mcke...@comcast.net**
wrote:
Jan;
No the outdated symbol is different. {{Delete}} Is a template that puts
the article in a special category to be deleted by an admin or by a bot.
Keith
jan iversen wrote:
Do you mean the outdated symbol, which should do just fine ??
Jan.
On 26 October 2012 17:18, Jürgen Schmidt jogischm...@gmail.com wrote:
On 10/25/12 9:19 PM, jan iversen wrote:
Maybe we could move them to an archive ??
I think we can find probably common consensus that we want to delete
pages to clean up this old stuff.
For example nobody needs today the old building guides. Let us focus on
the future and here I think less but correct and up-to-date information
is more.
When I remember correct there exist a template that could be used to
mark a page for deletion.
Simply put {{Delete}} on top of the page
Or we can create our own delete template with further instructions how
to proceed.
Administrator can for this from time to time and can delete stuff. Or
we
can try to cleanup such pages via a wiki bot.
Juergen
jan
On 25 October 2012 21:12, Alexandro Colorado j...@oooes.org wrote:
Nobody want to delete information and wiki pages only admin can
actually delete pages. Even then there might be some rights about
ownership. Is like sourceforge dont delete inactive projects.
Still good conversation to debate.
On 10/25/12, jan iversen jancasacon...@gmail.com wrote:
To my knowledge, articles that are marked outdated with a reference
to
a
newer article stays in Wiki.
Would it not be a good idea to remove such pages, in order not to
confuse
users ??
There are however no means, which I can find, to do that ?
Reason for my idea/question is that I am looking at localization
(l10n),
and there are a bit of old information.
Jan.
--
Alexandro Colorado
PPMC Apache OpenOffice
http://es.openoffice.org
Re: [proposal] Outdated articles in Wiki
So it is just a matter of having a checkbox next to the the search (upper
corner) ?
but I assume the setup of wiki is INFRA and not something we control
locally, so a change is not very easy (or how to request such a change) ?
jan.
On 26 October 2012 21:36, RGB ES rgb.m...@gmail.com wrote:
2012/10/26 jan iversen jancasacon...@gmail.com
Thanks for clearing that up. I have just been searching for build
instructions (again), and in the search response I cannot see if an
article
is outdated, so I had to open some before I got the correct one.
Would it be an idea (if possible) to have outdated as a category, and
extend the search to say with/without outdated, if possible that would
work
fine for me since I would hit the recent one when searching.
AFAIK, the outdated template also apply the outdated category:
http://wiki.openoffice.org/wiki/Category:Outdated
Regard
Ricardo
regards
Jan.
On 26 October 2012 21:16, Keith N. McKenna keith.mcke...@comcast.net
wrote:
Jan;
{{Documentation/Outdated}} and {{delete}} are two seperate entities.
Outdated merely says that some inormation is outdated and should be
revised. {{delete}} is a special case that marks a file for speedy
deletion
by an wiki administrator.
At least with the user documentation we tend to add to the document for
newer versions of the software rather than get rid of it as there are
still
people using older versions. This can however get carried to extremes.
My
personal opinion is that it is probably time to start seriously
considering purging version 2.x stuff, but that is a discussion for
another
thread.
Regards
Keith
jan iversen wrote:
So if an article is outdated, then it is ready for deletionor ???
Is it wise to have outdated articles alongside the correct/newer ones,
thinking of e.g. building instructions it would at least confuse me.
but I have no problem using {{Delete}} thanks for advicing me.
jan.
On 26 October 2012 19:03, Keith N. McKenna keith.mcke...@comcast.net
**
wrote:
Jan;
No the outdated symbol is different. {{Delete}} Is a template that
puts
the article in a special category to be deleted by an admin or by a
bot.
Keith
jan iversen wrote:
Do you mean the outdated symbol, which should do just fine ??
Jan.
On 26 October 2012 17:18, Jürgen Schmidt jogischm...@gmail.com
wrote:
On 10/25/12 9:19 PM, jan iversen wrote:
Maybe we could move them to an archive ??
I think we can find probably common consensus that we want to
delete
pages to clean up this old stuff.
For example nobody needs today the old building guides. Let us
focus
on
the future and here I think less but correct and up-to-date
information
is more.
When I remember correct there exist a template that could be used
to
mark a page for deletion.
Simply put {{Delete}} on top of the page
Or we can create our own delete template with further instructions
how
to proceed.
Administrator can for this from time to time and can delete stuff.
Or
we
can try to cleanup such pages via a wiki bot.
Juergen
jan
On 25 October 2012 21:12, Alexandro Colorado j...@oooes.org
wrote:
Nobody want to delete information and wiki pages only admin can
actually delete pages. Even then there might be some rights about
ownership. Is like sourceforge dont delete inactive projects.
Still good conversation to debate.
On 10/25/12, jan iversen jancasacon...@gmail.com wrote:
To my knowledge, articles that are marked outdated with a
reference
to
a
newer article stays in Wiki.
Would it not be a good idea to remove such pages, in order not
to
confuse
users ??
There are however no means, which I can find, to do that ?
Reason for my idea/question is that I am looking at localization
(l10n),
and there are a bit of old information.
Jan.
--
Alexandro Colorado
PPMC Apache OpenOffice
http://es.openoffice.org
Re: [RELEASE] Releasing new languages for 3.4.1
On 26 October 2012 23:06, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 10/26/2012 07:43 PM, schrieb Andrea Pescetti: Rob Weir wrote: 1) release new languages via lang packs only for now 2) release full installs, but for only these new languages I don't see a big difference between a langpack and a full install in this case, so I'd go for full installs, unless releasing langpacks helps in communicating that these are late additions and that full installs will come with the next release. Can we really skip the release process? PO files == source, right? Yes, not exactly but quite (PO files are not taken verbatim into source, but they are imported and influence resource files which are in the source tree). Maybe a question for legal-discuss if we're not certain. If in the end we have consensus on releasing new languages for 3.4.1 instead of making a new release, indeed we will ask. How do we want to handle this on an ongoing basis? New point release for every new language? Every 5 new languages? It is certainly good for volunteers to get the encouragement of a fast turnaround for their work. But this is the same for a C++ programmer. There are big differences here, that are also the reason for me to consider releasing these new languages as soon as possible: - A translation is often done by a team; if we can publish it immediately, the team can the be involved in other activities like revamping the N-L website, local promotion and so on; if we wait too much, we risk to have no volunteers for the following release. Really? I'm not that convinced that this would happen. When we communicate from the beginning when new loalizations will be released then everybody should be able to understand and handle this. - Releasing a new language is totally risk-free: a new language can't break functionality in OpenOffice, while any feature could have bugs and needs more qualified testing. Besides the comment from Jan I remember a case from the old OOo project. There were some translations for the names of Calc functions that got the same name but had to get (slightly) different names. The result was that there were 2-3 sum, 2-3 average, etc. functions. This was also - more or less the only - reason for another respin for a OOo RC; 3.2.1, 3.3.0, I don't remember anymore. So, the risk of new languages may not be high but I wouldn't say it's totally risk-free. In the end, I wonder whether the best solution is to get into a steady release cycle of quarterly releases (every 3 or 4 months)? +1 IMHO a regular release schedule is a very good idea. Then everybody can cope with this, can see when the next version will come and we can plan with a regular release plan (when to branch, freeze, localize, etc.). Of course the timeframe will need some discussions to find the right one. Previously it was tried to release every 6 months a new major release and every 6 months a point release. So, with overlapping there was a new release every 3 month. Maybe a good timeframe to continue? +1 to a relatively fixed time frame for new releases. Not only developers benefit from that but also end-users ! However do we have the logistic in place to handle ideas/request/bug fixes with these short intervals. It would mean (in my opinion) that we have an open catalog (new development) for 2-3 releases and have to prioritize within a limited timeframe what goes where ? We should also consider to apply a field in bugzilla, targeted for version. I really like the idea, but it has a tendency of killing long term developments, because they are hard to put into this framework, so we need something in the middle. This could be a solution too. In this case we would have the problem of choosing what to translate (3.4 or 3.5? probably we would ask new volunteers to focus on strings that will be in the next release, even though they aren't frozen yet). In any case we should continue to release new languages; regardless if major or point versions. Marcus
Re: The Impossible Question
Just an idea, which once helped me. Typically users dont think things will go wrong so they dont pay attention to whatever we write, but one apache project had a quite clever solution (if I remember right it was Axis, but dont depend on my memory), when the installation failed it did not just tell you failed, it came up with the link to FAQ, right when the user needed it, simple but very effective. jan. On 26 October 2012 23:06, Louis Suárez-Potts lo...@apache.org wrote: Hi Every now and then a user finds the experience of downloading, installing, using AOO disappointing and frankly frustrating if not worse. They will usually go to the user forums, but sometimes they will contact the Apache Foundation directly. Okay, but this does not really help them. What we did with OpenOffice was set up a Support page, which has since been moved to here, http://www.openoffice.org/support/. It's pretty much an improved version of the old but of course the ecosystem needs further fleshing out—it suffers from a lack of substantial existence. I'm also not persuaded that the route to it from either the application download page or homepage or wherever is redundantly clear enough for the befuddled enduser who installs AOO to replace his or her whatever suite and doesn't really know where to go….. So, my query is the usual impossible question: What can we do to make it clearer to the puzzled and frustrated how to get help? Sure, we can have a knowledge base (kb), FAQ, etc., and also enthusiastic community members. But what would you suggest as a path, or paths for the user? I personally would include something in the installation sets that point to the support page above; but also banners, say, or tags, stickers—glaringly obvious neon coloured blinking lights?—to relay users to useful pages. Ideas? Thanks Louis
Re: [RELEASE] Releasing new languages for 3.4.1
On 26 October 2012 23:38, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 10/26/2012 11:20 PM, schrieb jan iversen: On 26 October 2012 23:06, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/26/2012 07:43 PM, schrieb Andrea Pescetti: Rob Weir wrote: 1) release new languages via lang packs only for now 2) release full installs, but for only these new languages I don't see a big difference between a langpack and a full install in this case, so I'd go for full installs, unless releasing langpacks helps in communicating that these are late additions and that full installs will come with the next release. Can we really skip the release process? PO files == source, right? Yes, not exactly but quite (PO files are not taken verbatim into source, but they are imported and influence resource files which are in the source tree). Maybe a question for legal-discuss if we're not certain. If in the end we have consensus on releasing new languages for 3.4.1 instead of making a new release, indeed we will ask. How do we want to handle this on an ongoing basis? New point release for every new language? Every 5 new languages? It is certainly good for volunteers to get the encouragement of a fast turnaround for their work. But this is the same for a C++ programmer. There are big differences here, that are also the reason for me to consider releasing these new languages as soon as possible: - A translation is often done by a team; if we can publish it immediately, the team can the be involved in other activities like revamping the N-L website, local promotion and so on; if we wait too much, we risk to have no volunteers for the following release. Really? I'm not that convinced that this would happen. When we communicate from the beginning when new loalizations will be released then everybody should be able to understand and handle this. - Releasing a new language is totally risk-free: a new language can't break functionality in OpenOffice, while any feature could have bugs and needs more qualified testing. Besides the comment from Jan I remember a case from the old OOo project. There were some translations for the names of Calc functions that got the same name but had to get (slightly) different names. The result was that there were 2-3 sum, 2-3 average, etc. functions. This was also - more or less the only - reason for another respin for a OOo RC; 3.2.1, 3.3.0, I don't remember anymore. So, the risk of new languages may not be high but I wouldn't say it's totally risk-free. In the end, I wonder whether the best solution is to get into a steady release cycle of quarterly releases (every 3 or 4 months)? +1 IMHO a regular release schedule is a very good idea. Then everybody can cope with this, can see when the next version will come and we can plan with a regular release plan (when to branch, freeze, localize, etc.). Of course the timeframe will need some discussions to find the right one. Previously it was tried to release every 6 months a new major release and every 6 months a point release. So, with overlapping there was a new release every 3 month. Maybe a good timeframe to continue? +1 to a relatively fixed time frame for new releases. Not only developers benefit from that but also end-users ! Right However do we have the logistic in place to handle ideas/request/bug fixes with these short intervals. It would mean (in my opinion) that we have an OK, maybe the following fitts better to our current situation. Every 6 months a new major release and a point release on demand - enough new languages, urgent/severe bugfixes; that means outside a regular release plan. +1 open catalog (new development) for 2-3 releases and have to prioritize within a limited timeframe what goes where ? We should also consider to apply a field in bugzilla, targeted for version. That's already existing. Just look for the Target Milestone field. I think it is not really used (I might be wrong) but with frequent releases we should use it intensively, because today those who submit a bug must be pretty disappointed, I looked at a bug the other day, dated 2007 which are still a bug. I really like the idea, but it has a tendency of killing long term developments, because they are hard to put into this framework, so we need something in the middle. When we plan which new and planned feature goes into what release should work. I think I did not express it correctly, resources tend to be used for short term targets (next release, high motivation, lets make it folks, and after that we do all the rest). Marcus This could be a solution too. In this case we would have the problem of choosing what to translate (3.4 or 3.5? probably we would ask new volunteers to focus on strings that will be in the next release, even though they aren't frozen yet). In any case we should continue to release new languages
extensions and translations.
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/ how does that get integrated into the translation process ? As far as I can see the sources are not integrated into our build --all --with-lang. If I am right that they are not part of the general translation, then is that per design so or should it be different ? I might be following a wrong track here, but please forgive me for trying to make the l10n process as complete as I can. rgds Jan I.
Re: [RELEASE] Releasing new languages for 3.4.1
+1, being a non-native english speakng person, I want to ensure that we keep the AOO stability in language versions and not just see them as nice to have add-on !! jan On 27 October 2012 01:48, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: ... it would probably allow to skip the release process and voting, since we would merely be adding 3-5 binary artifacts (built for different platforms). It is an interesting question if we should only vote for source releases. Certainly these are the only official release. I think that the practice is to vote for binary packages as well. Clearly those have a different bar. It is worth discussing, but I am inclined to think that we do need to VOTE on these packages, but in this case we are voting at a certain level of trust for the packager and translations. Regards, Dave
Re: [RELEASE]: new snapshot base don revision r1400866
Juergen: could we use the snapshot build as basis for a branch where I can start working (and can you do it) ? Jan. On 25 October 2012 07:21, Ji Yan yanji...@gmail.com wrote: I'm downloading windows and mac install package and will do BVT and general testing against it. 2012/10/24 Jürgen Schmidt jogischm...@gmail.com Hi, a new snapshot build is available for MacOS and Windows. Linux will be available later. See https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds I have called it 3.5 snapshot but we haven't really confirmed if our next release will be a 3.5 or 4.0. That can be discussed and decided when we have finalized our plans. The snapshot is build on top of revision r1400866. I have provided full install set for all supported languages and a further language pack for en-US + the SDK and src release. Supported languages are: ar cs da de en-GB en-US es fi fr gd gl hu it ja km ko nb nl pt-BR ru sk sl zh-CN zh-TW @Ariel: I have changed columns in the wiki and moved MacOS before Linux, it makes it easier for me ;-) Juergen -- Thanks Best Regards, Yan Ji
Re: Directory main/swext/mediawiki
Hi I know the extensions does just thatI have not been using the site (now I get the confusion). In the AOO source tree there is a directory swext that contains the Wiki publisher source code. I will make a bug report, and give my solution as a patch. have a nice day jan. On 25 October 2012 10:25, Roberto Galoppini rgalopp...@geek.net wrote: On Wed, Oct 24, 2012 at 6:17 PM, jan iversen jancasacon...@gmail.com wrote: Roberto: I cannot tell if the problem is in the extension, but the behavior is as follow: 1) I do a confgure --with-lang --enable-wiki-publisher IT WORKS. 2) I do a configure --enable-wiki-publisher I get the license problem 3) I modify description.xml and remove the tag simple_license, and rebuilt/reinstall main/swext/mediawiki IT WORKS. So, please excuse me, but it seems to me that the extension do have a problem, or ??? The Extensions site justs hosts extensions, it doesn't know which options have been using to compile them, and the latest version was loaded by Sun and it's likely that who did it is not part of this project anymore. The build issues is definitely a good question, hope someone on ooo-dev can answer you on that. Roberto rgds Jan I. On 24 October 2012 12:52, Roberto Galoppini rgalopp...@geek.net wrote: On Tue, Oct 23, 2012 at 10:49 AM, jan iversen jancasacon...@gmail.com wrote: Thanks. I have not sent a specific request to you, but asked it as a general question (because I did not know who to ask). In the meantime, I found out that the sources in swext/mediawiki are in use, so I have compiled AOO with --enable-wiki-publisher. As far as I know http://extensions.openoffice.org/en/project/wikipublisher is based on 2009 source code, and it has not been updated since. Now my only problem is that, when I install the ocx via extension manager, I get a dialog box, stating that there might be a problem with description.xml because there is a license problem. I have tried to configure --with-lang=en, and rebuilt AOO, but that does not seem to help. I have no clue about why you get warnings, but I'm pretty sure this is not related to Extensions. Roberto So if you have an idea I would be thankfull. Are you working with the mediawiki sources, because the reason I do this was to fix a couple of problems I have found. Jan. On 23 October 2012 10:06, Roberto Galoppini rgalopp...@geek.net wrote: On Sun, Oct 21, 2012 at 6:24 PM, jan iversen jancasacon...@gmail.com wrote: I have looked for a newer source, since it was moved, but our own extensions has a broken link and sourceForge does not offer any help. Any ideas ?? Hi Jan, I don't think I've received any request from you, please let me know what's the problem, and I'll do my best to help you. Roberto It is a sun part, so we should have inherited it or not ? jan. On 20 October 2012 23:52, Alexandro Colorado j...@oooes.org wrote: On Sat, Oct 20, 2012 at 2:50 PM, jan iversen jancasacon...@gmail.com wrote: I am a bit confused. We have a directory named main/swext/mediawiki. Is that the sun wiki publisher 1.1 or are there 2 different mediawiki export extensions ? I ask because I sun wiki publisher 1.1 installed, but if I change the XLS and rebuilt AOO but it does not seem to have an effect. Yes I think it was started on core, and then sent to a separate extensions. Same thing happened with smarttags IIRC. Either I make a wrong assumption or life is not so simple as I would it to be :-) thanks in advance. jan. -- Alexandro Colorado PPMC Apache OpenOffice http://es.openoffice.org -- This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you. -- This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you.
Re: svn update, simple question.
Thanks for the information. Now I know what I did wrong, I did run configure again but not in a new shell (forgot the environment variables). I think the real hazzle is to understand the process, once you get the initial build done and understand a bit about the build/makefiles it is pretty clean. I worked in another project, where the build required you to open 3 shells, and start different commands at different stages, that was challenging compared to this :-) have a nice day. jan I. On 25 October 2012 11:03, Herbert Duerr h...@apache.org wrote: On 24.10.2012 18:54, jan iversen wrote: If I do a svn update trunk (I have all sources stored in directory trunk, do I then need to run configure again ??? In most cases you don't need to run configure again. my system seems to be spinning, after svn update I cannot run build in the single directories that all worked before svn update. Simple question, hopefully simple answer :-) The most simple answer is: do a clean build :-/ A less simple answer is in the rules of thumb below: 1. if the configure.in file was modified you need to run autoconf, then configure, and so on. Best in a new shell because they communicate with environment variables 2. if dependencies to external libraries were updated you need to run bootstrap again 3. if the interfaces of some modules changed then going into instsetoo_native and running build --all is recommended. There are issues with that though [1] that the buildbots suffer from in their incremental builds (as opposed to their clean builds). If there were not too many revisions since the last update then the chance that none of the points above apply is reasonable and not even the build --all is needed. It doesn't take too long though and is usually worth the time. This all shows that building AOO is still quite challenging. Making it easier and less error-prone is a very worthwhile goal, even if in practice this goal often loses against let's add a new feature, freshen up the UI or even fix a bug. [1] http://markmail.org/thread/**wmlhc5f5zaiiyu2ohttp://markmail.org/thread/wmlhc5f5zaiiyu2o Herbert
Re: [RELEASE]: new snapshot base don revision r1400866
Sorry for expressing it badly. Yes I do mean a branch based on the same version, because with the snapshot we know the state of the whole source (at least it is compileable). Jan. On 25 October 2012 11:28, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/25/12 9:04 AM, jan iversen wrote: Juergen: could we use the snapshot build as basis for a branch where I can start working (and can you do it) ? I am not sure if I get it, do you mean we should create a branch based on the same version? Juergen Jan. On 25 October 2012 07:21, Ji Yan yanji...@gmail.com wrote: I'm downloading windows and mac install package and will do BVT and general testing against it. 2012/10/24 Jürgen Schmidt jogischm...@gmail.com Hi, a new snapshot build is available for MacOS and Windows. Linux will be available later. See https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds I have called it 3.5 snapshot but we haven't really confirmed if our next release will be a 3.5 or 4.0. That can be discussed and decided when we have finalized our plans. The snapshot is build on top of revision r1400866. I have provided full install set for all supported languages and a further language pack for en-US + the SDK and src release. Supported languages are: ar cs da de en-GB en-US es fi fr gd gl hu it ja km ko nb nl pt-BR ru sk sl zh-CN zh-TW @Ariel: I have changed columns in the wiki and moved MacOS before Linux, it makes it easier for me ;-) Juergen -- Thanks Best Regards, Yan Ji
Re: svn update, simple question.
On 25 October 2012 13:03, Herbert Duerr h...@apache.org wrote: Hi Jan, On 25.10.2012 11:09, jan iversen wrote: Now I know what I did wrong, I did run configure again but not in a new shell (forgot the environment variables). Good. Do you happen to know which environment variables were the problem in this case? It would be great to have a mechanism that avoided this source of confusion but cleaning up such environment variables. AFAIK most of them are supposed to be unset in the script written by the bootstrap step. Yes at least I know one CC, I had for experimental use changed it to a different compiler, and configure used it for the Linux script. I will check next time to see if there are others. I think the real hazzle is to understand the process, once you get the initial build done and understand a bit about the build/makefiles it is pretty clean. I worked in another project, where the build required you to open 3 shells, and start different commands at different stages, that was challenging compared to this :-) Wow, that tops the complexity of the AOO build experience quite a bit. For an open-source project I'm afraid we're still way too challenging, especially since the project was disrupted in the transition from the classic OOo build system to a gnumake based system. Herbert
Re: apache2.conf file for openoffice.org server.
Thanks for your as usual very informative instructions. I did that, BUT it does not tell me which kind of SSI the apache server is using, there are two different methods: 1) using .shtml (which gives a problem with index.shtml) 2) setting excute bit on pages containing SSI, this requires XBitHack set in httpd.conf (or apache2.conf on ubuntu). that is my problem. I want to SSI for the top and bottom of each page, so I dont have a copy problem when we change e.g. mailling lists. I am by the way a long way down having a new l10n.openoffice.org ready for upload. Jan. On 25 October 2012 16:22, Rob Weir robw...@apache.org wrote: On Thu, Oct 25, 2012 at 6:48 AM, jan iversen jancasacon...@gmail.com wrote: Hi In order to test web page changes offline, I am configuring my own apache server, and would like to see the configuration of the openoffice.orgapache server, but I cannot find it in svn, can somebody help me, and mail it to me directly. There may be an easier way. Have you seen these instructions? http://incubator.apache.org/openofficeorg/website-local.html#how-to-do-website-development-locally-for-technical-users This gets the basic mdtext - HTML conversion working. It does not apply the site templates for the site-wide branding, etc. But for content development you really don't need to see that. -Rob thanks in advance. Juergen: do you know if we have ssi support ?
Re: Directory main/swext/mediawiki
Ups...that´s the problem, I will fix that. Tested a small change and it works. thanks. jan I On 25 October 2012 16:28, Andre Fischer awf@gmail.com wrote: On 24.10.2012 18:17, jan iversen wrote: Roberto: I cannot tell if the problem is in the extension, but the behavior is as follow: 1) I do a confgure --with-lang --enable-wiki-publisher IT WORKS. 2) I do a configure --enable-wiki-publisher I get the license problem 3) I modify description.xml and remove the tag simple_license, and rebuilt/reinstall main/swext/mediawiki IT WORKS. So, please excuse me, but it seems to me that the extension do have a problem, or ??? This may be connected to the head of swext/mediawiki/help/makefile.**mkhttp://makefile.mkwhere there is a special treatment of $WITH_LANG for when it contains en-US but mediawiki/help expects that to be just en. -Andre
Re: apache2.conf file for openoffice.org server.
Hi. I got the old l10n, and saw that in SVN it did not use templates, then I went on and checked the root (AOO) and also found no use of templates...I did find it a bit strange but assumed there were good reasons for not using templates, so I went down that road. But taking your advice, I will have another look at the templates (it is never too late to do a good thing). Jan. On 25 October 2012 17:55, Dave Fisher dave2w...@comcast.net wrote: On Oct 25, 2012, at 8:04 AM, jan iversen wrote: Thanks for your as usual very informative instructions. I did that, BUT it does not tell me which kind of SSI the apache server is using, there are two different methods: 1) using .shtml (which gives a problem with index.shtml) 2) setting excute bit on pages containing SSI, this requires XBitHack set in httpd.conf (or apache2.conf on ubuntu). I hope you have looked into the ooo-site/trunk/templates directory where you will see that the SSIs are not shtml. They are !-- virtual calls within the wrappers. I use a Mac and I did not have to anything special to make this SSI work. I'm not sure exactly how Apache Infra enables this, you should ask on IRC #asfinfra that is my problem. I want to SSI for the top and bottom of each page, so I dont have a copy problem when we change e.g. mailling lists. I am by the way a long way down having a new l10n.openoffice.org ready for upload. I hope you are not making special efforts with your own header and footer separate from what is already done in the Apache CMS. BTW - www.openoffice.org/l10n/ is where l10n.openoffice.org will be redirected. l10n code goes in ooo-site/tunk/content/l10n/ Regards, Dave Jan. On 25 October 2012 16:22, Rob Weir robw...@apache.org wrote: On Thu, Oct 25, 2012 at 6:48 AM, jan iversen jancasacon...@gmail.com wrote: Hi In order to test web page changes offline, I am configuring my own apache server, and would like to see the configuration of the openoffice.orgapache server, but I cannot find it in svn, can somebody help me, and mail it to me directly. There may be an easier way. Have you seen these instructions? http://incubator.apache.org/openofficeorg/website-local.html#how-to-do-website-development-locally-for-technical-users This gets the basic mdtext - HTML conversion working. It does not apply the site templates for the site-wide branding, etc. But for content development you really don't need to see that. -Rob thanks in advance. Juergen: do you know if we have ssi support ?
[proposal] Outdated articles in Wiki
To my knowledge, articles that are marked outdated with a reference to a newer article stays in Wiki. Would it not be a good idea to remove such pages, in order not to confuse users ?? There are however no means, which I can find, to do that ? Reason for my idea/question is that I am looking at localization (l10n), and there are a bit of old information. Jan.
Re: [proposal] Outdated articles in Wiki
Maybe we could move them to an archive ?? jan On 25 October 2012 21:12, Alexandro Colorado j...@oooes.org wrote: Nobody want to delete information and wiki pages only admin can actually delete pages. Even then there might be some rights about ownership. Is like sourceforge dont delete inactive projects. Still good conversation to debate. On 10/25/12, jan iversen jancasacon...@gmail.com wrote: To my knowledge, articles that are marked outdated with a reference to a newer article stays in Wiki. Would it not be a good idea to remove such pages, in order not to confuse users ?? There are however no means, which I can find, to do that ? Reason for my idea/question is that I am looking at localization (l10n), and there are a bit of old information. Jan. -- Alexandro Colorado PPMC Apache OpenOffice http://es.openoffice.org
Re: AOO volunteers: essential skills and tasks
+1, that was something I could really have used some weeks ago :-) Maybe a word about active volunteers might not be harmful (I think I am in that state now) Jan I. On 23 October 2012 23:30, Rob Weir robw...@apache.org wrote: On Fri, Oct 19, 2012 at 12:17 PM, Rob Weir robw...@apache.org wrote: I am thinking about what new project volunteers need to get started. Obviously there are area-specific things. For example, developers need to know how to download and build. Translation volunteers need to understand Pootle, etc. But there are also some basic things that all volunteers should probably do. Although we have all of this information (or at least most of it) on the website or wikis or mailing list archives, it is scattered all over the place. I think it would be good if we could collect this information (or at least links to this information) into one place and put a linear order behind it, a step of specific steps we want new volunteers to take. Now, I can hear the objections already -- you can't tell volunteers what to do. That is why they are volunteers. You can't regiment them, etc. This is true. But at the scale we need to operate at -- I'm aiming to attract dozens of new volunteers on the project by the end of the year -- we need some structure. So what can we do to make their first 2 weeks in the project easier for them, and easier for us? One idea: Think of the new volunteer startup tasks in terms of stages or levels, a defined set of reading and other activities that leads them to acquire basic skills in our community. For example: Level 1 tasks: 1) Read the following web pages on the ASF, roles at Apache and the Apache Way 2) Sign up for the following accounts that every volunteer should have: ooo-announce, ooo-dev, ooo-users, MWiki, CWiki, BZ, Forums 3) Read this helpful document on hints for managing your inbox with rules and folders 4) Read this code of conduct page on list etiquette 5) Send a note to ooo-dev list and introduce yourself 6) Edit this wiki page containing project volunteers. Add your name and indicate that you have completed Level 1. Level 2 tasks: 1) Using the Apache CMS in anonymous mode 2) Readings on decision making at Apache 3) Readings on project life cycle and roles within the AOO project 4) Introduction to the various functional groups within the project: development, qa, marketing, UX, documentation, support, localization, etc. 5) Pick one or more functional groups that you want to help with. Edit the volunteer wiki and list them. Also indicate that you have now completed Level 2. Get the idea? After Level 2 this then could branch off into area-specific lists of start up tasks: how to download and build. How to submit patches. How to update a translation. How to define a new test case. Is any one interested in helping with this? Quick update. I have drafts of a few of the pages ready. 1) New Volunteer Orientation root page: http://incubator.apache.org/openofficeorg/orientation/ 2) Introduction to Contributing to Apache OpenOffice (Level 1): http://incubator.apache.org/openofficeorg/orientation/level-1.html 3) Intermediate Social and Technical Tools (Level 2): http://incubator.apache.org/openofficeorg/orientation/level-2.html (around half done). I could really use some help drafting the area-specific Level 3 and Level 4 pages, from subject matter experts. -Rob
Re: Directory main/swext/mediawiki
Roberto: I cannot tell if the problem is in the extension, but the behavior is as follow: 1) I do a confgure --with-lang --enable-wiki-publisher IT WORKS. 2) I do a configure --enable-wiki-publisher I get the license problem 3) I modify description.xml and remove the tag simple_license, and rebuilt/reinstall main/swext/mediawiki IT WORKS. So, please excuse me, but it seems to me that the extension do have a problem, or ??? rgds Jan I. On 24 October 2012 12:52, Roberto Galoppini rgalopp...@geek.net wrote: On Tue, Oct 23, 2012 at 10:49 AM, jan iversen jancasacon...@gmail.com wrote: Thanks. I have not sent a specific request to you, but asked it as a general question (because I did not know who to ask). In the meantime, I found out that the sources in swext/mediawiki are in use, so I have compiled AOO with --enable-wiki-publisher. As far as I know http://extensions.openoffice.org/en/project/wikipublisher is based on 2009 source code, and it has not been updated since. Now my only problem is that, when I install the ocx via extension manager, I get a dialog box, stating that there might be a problem with description.xml because there is a license problem. I have tried to configure --with-lang=en, and rebuilt AOO, but that does not seem to help. I have no clue about why you get warnings, but I'm pretty sure this is not related to Extensions. Roberto So if you have an idea I would be thankfull. Are you working with the mediawiki sources, because the reason I do this was to fix a couple of problems I have found. Jan. On 23 October 2012 10:06, Roberto Galoppini rgalopp...@geek.net wrote: On Sun, Oct 21, 2012 at 6:24 PM, jan iversen jancasacon...@gmail.com wrote: I have looked for a newer source, since it was moved, but our own extensions has a broken link and sourceForge does not offer any help. Any ideas ?? Hi Jan, I don't think I've received any request from you, please let me know what's the problem, and I'll do my best to help you. Roberto It is a sun part, so we should have inherited it or not ? jan. On 20 October 2012 23:52, Alexandro Colorado j...@oooes.org wrote: On Sat, Oct 20, 2012 at 2:50 PM, jan iversen jancasacon...@gmail.com wrote: I am a bit confused. We have a directory named main/swext/mediawiki. Is that the sun wiki publisher 1.1 or are there 2 different mediawiki export extensions ? I ask because I sun wiki publisher 1.1 installed, but if I change the XLS and rebuilt AOO but it does not seem to have an effect. Yes I think it was started on core, and then sent to a separate extensions. Same thing happened with smarttags IIRC. Either I make a wrong assumption or life is not so simple as I would it to be :-) thanks in advance. jan. -- Alexandro Colorado PPMC Apache OpenOffice http://es.openoffice.org -- This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you.
Re: [SOURCE]: code repo move after graduation
Question: If have made a svn co on the incubator version, will I have to do a new svn co on the new path, or will svn update (as usual) work ??? rgds Jan I. On 24 October 2012 18:16, Pedro Giffuni p...@apache.org wrote: +1 openoffice Ditto for bugzilla. Pedro. ps. FWIW, it would've been nice to attempt to rescue the history and put it under the carpet (even just the SVN stuff was useful) but it's a lot more work than anyone would care to do at this point. - Original Message - From: imacat Subject: Re: [SOURCE]: code repo move after graduation On 2012/10/24 19:43, Jürgen Schmidt said: On 10/24/12 1:40 PM, Jürgen Schmidt wrote: Hi, jira issue https://issues.apache.org/jira/browse/INFRA-5417 covers the move of the source repository into the new final place as part of our post graduation tasks. I am thinking if we can and should rename it from ooo to aoo to reflect the name Apache OpenOffice instead of OpenOffice .org. ok, I noticed that Dave suggested already to use the complete name openoffice in the issue which is of course the best solution. openoffice agree! ^_*' This makes my email obsolete. Juergen -- Best regards, imacat ^_*' ima...@mail.imacat.idv.tw PGP Key http://www.imacat.idv.tw/me/pgpkey.asc Woman's Voice News: http://www.wov.idv.tw/ Tavern IMACAT's http://www.imacat.idv.tw/ Woman in FOSS in Taiwan http://wofoss.blogspot.com/ OpenOffice http://www.openoffice.org/ EducOO/OOo4Kids Taiwan http://www.educoo.tw/ Greenfoot Taiwan http://greenfoot.westart.tw/
Re: AOO volunteers: essential skills and tasks
After a day of work, maybe I should elaborate on what I mean: Having read your documents in detail, which I really find SUPER, I see one challenge: old people in the mailing list pretty much knows who is working on (sort of responsible for) a given part, so they have no problems with proposals since they know who to approach, and the JFDI methods works well. new volunteers who wants to follow what happens and do a little here and there, will typically not make [proposals] but do JFDI on the wiki, and otherwise look for questions. The last part, those who want to be integrated and help move things, do have a slight problem: [proposals] might not even be responded to, especially if they fall in one of two catagories: - this is something we have discussed before - somebody is working on the theme JFDI method might be even worse, because you spent hours doing something sent it off to a committer and zero I believe in both methods, but I really believe that JFDI should be AFJFDI (asf first if anyone is working on it), and then do it. The proposal part is a bit harder, and maybe your document should state wait with proposals until you are integrated in the commnity. once again, your document are SUPER...the rest is just my experience. jan. On 24 October 2012 10:09, jan iversen jancasacon...@gmail.com wrote: +1, that was something I could really have used some weeks ago :-) Maybe a word about active volunteers might not be harmful (I think I am in that state now) Jan I. On 23 October 2012 23:30, Rob Weir robw...@apache.org wrote: On Fri, Oct 19, 2012 at 12:17 PM, Rob Weir robw...@apache.org wrote: I am thinking about what new project volunteers need to get started. Obviously there are area-specific things. For example, developers need to know how to download and build. Translation volunteers need to understand Pootle, etc. But there are also some basic things that all volunteers should probably do. Although we have all of this information (or at least most of it) on the website or wikis or mailing list archives, it is scattered all over the place. I think it would be good if we could collect this information (or at least links to this information) into one place and put a linear order behind it, a step of specific steps we want new volunteers to take. Now, I can hear the objections already -- you can't tell volunteers what to do. That is why they are volunteers. You can't regiment them, etc. This is true. But at the scale we need to operate at -- I'm aiming to attract dozens of new volunteers on the project by the end of the year -- we need some structure. So what can we do to make their first 2 weeks in the project easier for them, and easier for us? One idea: Think of the new volunteer startup tasks in terms of stages or levels, a defined set of reading and other activities that leads them to acquire basic skills in our community. For example: Level 1 tasks: 1) Read the following web pages on the ASF, roles at Apache and the Apache Way 2) Sign up for the following accounts that every volunteer should have: ooo-announce, ooo-dev, ooo-users, MWiki, CWiki, BZ, Forums 3) Read this helpful document on hints for managing your inbox with rules and folders 4) Read this code of conduct page on list etiquette 5) Send a note to ooo-dev list and introduce yourself 6) Edit this wiki page containing project volunteers. Add your name and indicate that you have completed Level 1. Level 2 tasks: 1) Using the Apache CMS in anonymous mode 2) Readings on decision making at Apache 3) Readings on project life cycle and roles within the AOO project 4) Introduction to the various functional groups within the project: development, qa, marketing, UX, documentation, support, localization, etc. 5) Pick one or more functional groups that you want to help with. Edit the volunteer wiki and list them. Also indicate that you have now completed Level 2. Get the idea? After Level 2 this then could branch off into area-specific lists of start up tasks: how to download and build. How to submit patches. How to update a translation. How to define a new test case. Is any one interested in helping with this? Quick update. I have drafts of a few of the pages ready. 1) New Volunteer Orientation root page: http://incubator.apache.org/openofficeorg/orientation/ 2) Introduction to Contributing to Apache OpenOffice (Level 1): http://incubator.apache.org/openofficeorg/orientation/level-1.html 3) Intermediate Social and Technical Tools (Level 2): http://incubator.apache.org/openofficeorg/orientation/level-2.html (around half done). I could really use some help drafting the area-specific Level 3 and Level 4 pages, from subject matter experts. -Rob
svn update, simple question.
Hi. If I do a svn update trunk (I have all sources stored in directory trunk, do I then need to run configure again ??? my system seems to be spinning, after svn update I cannot run build in the single directories that all worked before svn update. Simple question, hopefully simple answer :-) jan.
Re: AOO volunteers: essential skills and tasks
+1 Anything is better than nothing !!! and afterwards it can be improved. jan On 24 October 2012 18:49, Kay Schenk kay.sch...@gmail.com wrote: On 10/24/2012 09:40 AM, Rob Weir wrote: On Wed, Oct 24, 2012 at 12:30 PM, jan iversen jancasacon...@gmail.com wrote: After a day of work, maybe I should elaborate on what I mean: Having read your documents in detail, which I really find SUPER, I see one challenge: old people in the mailing list pretty much knows who is working on (sort of responsible for) a given part, so they have no problems with proposals since they know who to approach, and the JFDI methods works well. new volunteers who wants to follow what happens and do a little here and there, will typically not make [proposals] but do JFDI on the wiki, and otherwise look for questions. The last part, those who want to be integrated and help move things, do have a slight problem: [proposals] might not even be responded to, especially if they fall in one of two catagories: - this is something we have discussed before - somebody is working on the theme JFDI method might be even worse, because you spent hours doing something sent it off to a committer and zero This is also a possible conflict between two new volunteers, or even two old volunteers. If you go off and work on something for a month without telling anyone, then you risk that someone old or new does the same thing, or similar. That is a point worth mentioning, that for larger jobs, you might want to mention it on the list, not because it is controversial, but just for coordination purposes, so others are aware. Maybe they even offer to help or give some helpful ideas. I can include these ideas in the text. I believe in both methods, but I really believe that JFDI should be AFJFDI (asf first if anyone is working on it), and then do it. The proposal part is a bit harder, and maybe your document should state wait with proposals until you are integrated in the commnity. Certainly for larger tasks, this makes sense. But if it is a quick operation then JFDI works. I suppose it depends on the time-to-JFDI/time-to-post-and-**wait-72-hours ratio. For new volunteers they don't have access to SVN, so everything they do is essentially RTC. So submitting their patches is essentially like making a proposal. But the same considerations apply. It might make sense to float the idea first before investing a lot of time in the work. once again, your document are SUPER...the rest is just my experience. jan. On 24 October 2012 10:09, jan iversen jancasacon...@gmail.com wrote: +1, that was something I could really have used some weeks ago :-) Maybe a word about active volunteers might not be harmful (I think I am in that state now) Jan I. On 23 October 2012 23:30, Rob Weir robw...@apache.org wrote: On Fri, Oct 19, 2012 at 12:17 PM, Rob Weir robw...@apache.org wrote: I am thinking about what new project volunteers need to get started. Obviously there are area-specific things. For example, developers need to know how to download and build. Translation volunteers need to understand Pootle, etc. But there are also some basic things that all volunteers should probably do. Although we have all of this information (or at least most of it) on the website or wikis or mailing list archives, it is scattered all over the place. I think it would be good if we could collect this information (or at least links to this information) into one place and put a linear order behind it, a step of specific steps we want new volunteers to take. Now, I can hear the objections already -- you can't tell volunteers what to do. That is why they are volunteers. You can't regiment them, etc. This is true. But at the scale we need to operate at -- I'm aiming to attract dozens of new volunteers on the project by the end of the year -- we need some structure. So what can we do to make their first 2 weeks in the project easier for them, and easier for us? One idea: Think of the new volunteer startup tasks in terms of stages or levels, a defined set of reading and other activities that leads them to acquire basic skills in our community. For example: Level 1 tasks: 1) Read the following web pages on the ASF, roles at Apache and the Apache Way 2) Sign up for the following accounts that every volunteer should have: ooo-announce, ooo-dev, ooo-users, MWiki, CWiki, BZ, Forums 3) Read this helpful document on hints for managing your inbox with rules and folders 4) Read this code of conduct page on list etiquette 5) Send a note to ooo-dev list and introduce yourself 6) Edit this wiki page containing project volunteers. Add your name and indicate that you have completed Level 1. Level 2 tasks: 1) Using the Apache CMS in anonymous mode 2) Readings on decision making at Apache 3) Readings on project life cycle and roles within the AOO project 4
Re: discussion on new l10n workflow
Thanks for your kind words. see below please: On 24 October 2012 19:49, Louis Suárez-Potts lui...@gmail.com wrote: Hi Jan, On 12-10-16, at 12:22 , jan iversen jancasacon...@gmail.com wrote: Finally I have finished describing the current process, and also combining all the notes on open issues I could find. Thanks. A lot of work. Last it was dealt with was probably (prior to Apache's advent) back in…. I hate to say, last century. Please have a look at: http://wiki.openoffice.org/wiki/File:L10proc.pdf Indeed. and http://wiki.openoffice.org/wiki/Localization_AOO I hope we can have a discussion on the open issues, and then I will make a design document for a changed workflow. I look forward to hear your opinion, either through wiki or mail. These comments will be worked into the document. have a nice day. jan I I'll go over it. Usually, as others no doubt will mention, my impression is that a big issue has always been qualifying the outcome, incorporating input, and normalizing it, so that what happens in, say, January, can be expected to continue on into the future. It was a big job, first describing the current process and run it several times to make sure I understood it, and then think about how to do more robust and future oriented. I have had a helping hand from my professional background where I used to manage project with these kind of problemsets. I would appreciate any input, this is a floating process, development/discussion. A sidle point has perhaps also do with working with the LibreOffice team—and others working using similar strings, e.g., those nice people at that Mozilla project, among others. Under the Sun regime, licensing issues foreclosed that option. I'd hate to think we are still hobbled by political considerations and that these undercut the terrific enterprise of people like you. I am very open minded to that respect, but honestly I have no idea what the apache policy is. Thanks Louis
Re: discussion on new l10n workflow
May I politely ask if there are other comments or more importantly objections ? If not I will continue with the process and keep you posted, please remember comments are also welcome as the new workflow takes shape. Jan I. On 24 October 2012 20:18, jan iversen jancasacon...@gmail.com wrote: Thanks for your kind words. see below please: On 24 October 2012 19:49, Louis Suárez-Potts lui...@gmail.com wrote: Hi Jan, On 12-10-16, at 12:22 , jan iversen jancasacon...@gmail.com wrote: Finally I have finished describing the current process, and also combining all the notes on open issues I could find. Thanks. A lot of work. Last it was dealt with was probably (prior to Apache's advent) back in…. I hate to say, last century. Please have a look at: http://wiki.openoffice.org/wiki/File:L10proc.pdf Indeed. and http://wiki.openoffice.org/wiki/Localization_AOO I hope we can have a discussion on the open issues, and then I will make a design document for a changed workflow. I look forward to hear your opinion, either through wiki or mail. These comments will be worked into the document. have a nice day. jan I I'll go over it. Usually, as others no doubt will mention, my impression is that a big issue has always been qualifying the outcome, incorporating input, and normalizing it, so that what happens in, say, January, can be expected to continue on into the future. It was a big job, first describing the current process and run it several times to make sure I understood it, and then think about how to do more robust and future oriented. I have had a helping hand from my professional background where I used to manage project with these kind of problemsets. I would appreciate any input, this is a floating process, development/discussion. A sidle point has perhaps also do with working with the LibreOffice team—and others working using similar strings, e.g., those nice people at that Mozilla project, among others. Under the Sun regime, licensing issues foreclosed that option. I'd hate to think we are still hobbled by political considerations and that these undercut the terrific enterprise of people like you. I am very open minded to that respect, but honestly I have no idea what the apache policy is. Thanks Louis
Re: Volunteers, Contributors, Committers, PMC members -- is there any way to consolidate these lists?
On 24 October 2012 20:56, Rob Weir robw...@apache.org wrote: We have the following today: 1) http://incubator.apache.org/openofficeorg/people.html -- This lists a variety of people involved in the project, independent of status. 2) I'd like to have a place for new volunteers to put their names, preferably on the wiki or some place where a non-committer has easy access. +1, very good idea...but may I suggest that we formalize the skill set description a bit (sort of check boxes), and add a field interest in AOO, (e.g. l10n) making it easier for others to see where help can come from. 3) We have a list of Committers here, automatically generated: http://people.apache.org/committers-by-project.html#ooo I would be nice to know the same about committers, and especially which areas the commit, I know in theory all, but I assume in praxise the areas they know well. 4) We don't have anything that indicates which Committers are also PMC members. Is that an important difference in daily life ? 5) We have this credits page, which is linked to from our Help/About dialog box. But it does not appear to be updated for AOO 3.4.0 or 3.4.1: http://www.openoffice.org/welcome/credits.html 6) Wiki User pages 7) Any others? As we all know, with multiple lists like this things will get out of synch. In fact they already have. One simplification idea might be: 1) Convert the people.html page into a wiki page +1 and merge with contributors ?? 2) Have that page indicate who is a Committer or PMC member. That can be manual for now. 3) Point our Help/About box to the wiki page, and add sentence at the end of the wiki that says, OpenOffice has a long history and we also thank those who contributed to it before our move to Apache and then link to credits.html Any objections to this general idea? Any improvements? And if we did want a place to have a big table of volunteers, where on the wiki should we put it (CWiki or MWiki)? MWiki...that is OUR wiki, CWiki is for whole apache or ? -Rob
Re: [PROPOSAL] difficulty field for Bugzilla
+1 On 24 October 2012 21:08, Rob Weir robw...@apache.org wrote: As you have probably noticed, I'm engaged in a variety of initiatives to grow the community, bring in more volunteers, etc. One additional piece that I think would be useful is to add a new field to Bugzilla to indicate the difficulty level of the bug. Of course, this will often not be known. But in some cases, we do know, and where we do know we can indicate this. What this allows us to do is then have search filters that return only open easy bugs. These are ideal for new developer volunteers on the project who are looking for items that match their lesser familiarity with the code. It also allows a developer to step up to more challenging bugs over time. A similar approach, which they called easy hacks, was successfully used by LibreOffice. If there are no objections, I'll add a new field to Bugzilla called cf_difficulty_level, and which a drop down UI with the following choices: UNKNOWN (default) TRIVIAL EASY MODERATE HARD WIZARD (I'm certainly open to variations on the names) I'd then rely on other developers to help seed the database with some TRIVIAL and EASY bugs, so new volunteers will have something to work with as they familiarize themselves with the project. I'll wait 72 hours, etc. Regards, -Rob
Re: discussion on new l10n workflow
Where can I read more about ApacheCon EU or NA ? I cannot quite follow you here (mainly due to terms), is this about getting sponsor money to AOO ? It should be easy to get somebody from EU and others, I could call on the NLC to help QA and general testing. jan. On 24 October 2012 21:53, Louis Suárez-Potts lui...@gmail.com wrote: On 12-10-24, at 14:35 , jan iversen jancasacon...@gmail.com wrote: May I politely ask if there are other comments or more importantly objections ? Press on. And expect to be patient: this is a volunteer effort. I 'd also, if I were you, see about highlighting this effort at ApacheCon EU or NA (next year). If you cannot personally make the EU event, you can ask a surrogate, perhaps. But the issue is indeed very important, at least as I see it. For it leads to expanding the AOO contributor base, being that localization efforts are among the most interesting to a range of audiences, who rightly see a localized AOO as much easier to work with than one in English. If not I will continue with the process and keep you posted, please remember comments are also welcome as the new workflow takes shape. Please! also, don't hesitate to use other channels, such as Facebook, our wikis, etc. best louis Jan I. On 24 October 2012 20:18, jan iversen jancasacon...@gmail.com wrote: Thanks for your kind words. see below please: On 24 October 2012 19:49, Louis Suárez-Potts lui...@gmail.com wrote: Hi Jan, On 12-10-16, at 12:22 , jan iversen jancasacon...@gmail.com wrote: Finally I have finished describing the current process, and also combining all the notes on open issues I could find. Thanks. A lot of work. Last it was dealt with was probably (prior to Apache's advent) back in…. I hate to say, last century. Please have a look at: http://wiki.openoffice.org/wiki/File:L10proc.pdf Indeed. and http://wiki.openoffice.org/wiki/Localization_AOO I hope we can have a discussion on the open issues, and then I will make a design document for a changed workflow. I look forward to hear your opinion, either through wiki or mail. These comments will be worked into the document. have a nice day. jan I I'll go over it. Usually, as others no doubt will mention, my impression is that a big issue has always been qualifying the outcome, incorporating input, and normalizing it, so that what happens in, say, January, can be expected to continue on into the future. It was a big job, first describing the current process and run it several times to make sure I understood it, and then think about how to do more robust and future oriented. I have had a helping hand from my professional background where I used to manage project with these kind of problemsets. I would appreciate any input, this is a floating process, development/discussion. A sidle point has perhaps also do with working with the LibreOffice team—and others working using similar strings, e.g., those nice people at that Mozilla project, among others. Under the Sun regime, licensing issues foreclosed that option. I'd hate to think we are still hobbled by political considerations and that these undercut the terrific enterprise of people like you. I am very open minded to that respect, but honestly I have no idea what the apache policy is. Thanks Louis
Re: discussion on new l10n workflow
Got it, I did not think of the upcoming meeting. I think it is too early for that (maybe somebody has opinions??) I would like to present it, when it is ready to be launched...I dont like to present hot air :-) But as I understood it there is another conference early next year, that would be just perfect. jan. On 24 October 2012 22:08, Joost Andrae joost.and...@gmx.de wrote: Hi Jan, more information about ApacheCon can be found here: http://www.apachecon.eu/ Am 24.10.2012 22:03, schrieb jan iversen: Where can I read more about ApacheCon EU or NA ? I cannot quite follow you here (mainly due to terms), is this about getting sponsor money to AOO ? It should be easy to get somebody from EU and others, I could call on the NLC to help QA and general testing. Kind regards, Joost
Re: Directory main/swext/mediawiki
Thanks. I have not sent a specific request to you, but asked it as a general question (because I did not know who to ask). In the meantime, I found out that the sources in swext/mediawiki are in use, so I have compiled AOO with --enable-wiki-publisher. Now my only problem is that, when I install the ocx via extension manager, I get a dialog box, stating that there might be a problem with description.xml because there is a license problem. I have tried to configure --with-lang=en, and rebuilt AOO, but that does not seem to help. So if you have an idea I would be thankfull. Are you working with the mediawiki sources, because the reason I do this was to fix a couple of problems I have found. Jan. On 23 October 2012 10:06, Roberto Galoppini rgalopp...@geek.net wrote: On Sun, Oct 21, 2012 at 6:24 PM, jan iversen jancasacon...@gmail.com wrote: I have looked for a newer source, since it was moved, but our own extensions has a broken link and sourceForge does not offer any help. Any ideas ?? Hi Jan, I don't think I've received any request from you, please let me know what's the problem, and I'll do my best to help you. Roberto It is a sun part, so we should have inherited it or not ? jan. On 20 October 2012 23:52, Alexandro Colorado j...@oooes.org wrote: On Sat, Oct 20, 2012 at 2:50 PM, jan iversen jancasacon...@gmail.com wrote: I am a bit confused. We have a directory named main/swext/mediawiki. Is that the sun wiki publisher 1.1 or are there 2 different mediawiki export extensions ? I ask because I sun wiki publisher 1.1 installed, but if I change the XLS and rebuilt AOO but it does not seem to have an effect. Yes I think it was started on core, and then sent to a separate extensions. Same thing happened with smarttags IIRC. Either I make a wrong assumption or life is not so simple as I would it to be :-) thanks in advance. jan. -- Alexandro Colorado PPMC Apache OpenOffice http://es.openoffice.org -- This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you.
Re: Updated Stats page
+1, fine page. Monthly should be enough. Would it be worth to consider to include the country discussion (e.g. list top 5 countries, and the total number) ? Jan. On 23 October 2012 17:20, Rob Weir robw...@apache.org wrote: I've moved the download stats to its own page: http://www.openoffice.org/stats/downloads.html That allowed me to give a fuller description of what the stats are, how they were gathered, etc. I think we should aim for this level of detail and transparency in any claims we make. This move then allowed me to clean up the Stats home page a little, and include links to other charts we have, as well as add a section (with caveats) on 3rd party stats: http://www.openoffice.org/stats/ If anyone has ideas for other relevant stats that might be interested, I'd be interested in adding more. I can help on the data wrangling and charting side.I'd love to have a regular chart on wiki and forums traffic or edits or posts or whatever. This doesn't need to be totally automated. For example, it could be something where someone volunteers to run a monthly report and posts that new stat once a month. Regards, -Rob
Re: Updated Stats page
A report would serve the same purpose, and posted with regular intervals (like 1 month), with figures based on e.g. last month, last half year. jan. On 23 October 2012 18:00, Rob Weir robw...@apache.org wrote: On Tue, Oct 23, 2012 at 11:23 AM, jan iversen jancasacon...@gmail.com wrote: +1, fine page. Monthly should be enough. Would it be worth to consider to include the country discussion (e.g. list top 5 countries, and the total number) ? I'll take a look to see if there is anything interesting here. But my guess is the top 5 countries will be static over time, and would not be an interesting chart or a time series. But maybe we could periodically post a table of these numbers? I have a pythons script that gathers these numbers and generates a CSV report. It would be easy to have it write out an HTML page instead. -Rob Jan. On 23 October 2012 17:20, Rob Weir robw...@apache.org wrote: I've moved the download stats to its own page: http://www.openoffice.org/stats/downloads.html That allowed me to give a fuller description of what the stats are, how they were gathered, etc. I think we should aim for this level of detail and transparency in any claims we make. This move then allowed me to clean up the Stats home page a little, and include links to other charts we have, as well as add a section (with caveats) on 3rd party stats: http://www.openoffice.org/stats/ If anyone has ideas for other relevant stats that might be interested, I'd be interested in adding more. I can help on the data wrangling and charting side.I'd love to have a regular chart on wiki and forums traffic or edits or posts or whatever. This doesn't need to be totally automated. For example, it could be something where someone volunteers to run a monthly report and posts that new stat once a month. Regards, -Rob
Re: Extensions website unavailable?
I have no problem with download, but extensions is down seen from spain as well, but extensions have been rather unstable the last couple of days. I do not know why. jan On 23 October 2012 17:31, John Myerson john.myer...@blueyonder.co.ukwrote: The link http://extensions.services.openoffice.org/ from http://www.openoffice.org/download/ is not available at present. John Myerson
Re: Updated Stats page
+1 to both the page you just made and the idea of a new column with regular intervals. Jan. On 23 October 2012 20:48, Rob Weir robw...@apache.org wrote: On Tue, Oct 23, 2012 at 12:10 PM, jan iversen jancasacon...@gmail.com wrote: A report would serve the same purpose, and posted with regular intervals (like 1 month), with figures based on e.g. last month, last half year. OK. I posted a snapshot of the downloads since AOO 3.4.0 was released back in May: http://www.openoffice.org/stats/countries.html One option would be to repeat this in 3 months or whatever, and add a new column and % difference for each country. -Rob jan. On 23 October 2012 18:00, Rob Weir robw...@apache.org wrote: On Tue, Oct 23, 2012 at 11:23 AM, jan iversen jancasacon...@gmail.com wrote: +1, fine page. Monthly should be enough. Would it be worth to consider to include the country discussion (e.g. list top 5 countries, and the total number) ? I'll take a look to see if there is anything interesting here. But my guess is the top 5 countries will be static over time, and would not be an interesting chart or a time series. But maybe we could periodically post a table of these numbers? I have a pythons script that gathers these numbers and generates a CSV report. It would be easy to have it write out an HTML page instead. -Rob Jan. On 23 October 2012 17:20, Rob Weir robw...@apache.org wrote: I've moved the download stats to its own page: http://www.openoffice.org/stats/downloads.html That allowed me to give a fuller description of what the stats are, how they were gathered, etc. I think we should aim for this level of detail and transparency in any claims we make. This move then allowed me to clean up the Stats home page a little, and include links to other charts we have, as well as add a section (with caveats) on 3rd party stats: http://www.openoffice.org/stats/ If anyone has ideas for other relevant stats that might be interested, I'd be interested in adding more. I can help on the data wrangling and charting side.I'd love to have a regular chart on wiki and forums traffic or edits or posts or whatever. This doesn't need to be totally automated. For example, it could be something where someone volunteers to run a monthly report and posts that new stat once a month. Regards, -Rob
Re: Directory main/swext/mediawiki
Thanks, I thought --all meant just compiling it all :-) I tried to do man build to get a list of all switches, which of course did not work. Is there a place (build config file or so) to look for all the switches. JanI On 22 October 2012 10:36, Herbert Duerr h...@apache.org wrote: On 21.10.2012 18:16, jan iversen wrote: Now I am the one that is confused (again). Is the directory mediaWiki active or not ? The extension in that directory is built only if you used the --enable-wiki-publisher configure option. Herbert
Re: Directory main/swext/mediawiki
Sorry, You wrote configure option...please forget my mail. janI On 22 October 2012 10:49, jan iversen jancasacon...@gmail.com wrote: Thanks, I thought --all meant just compiling it all :-) I tried to do man build to get a list of all switches, which of course did not work. Is there a place (build config file or so) to look for all the switches. JanI On 22 October 2012 10:36, Herbert Duerr h...@apache.org wrote: On 21.10.2012 18:16, jan iversen wrote: Now I am the one that is confused (again). Is the directory mediaWiki active or not ? The extension in that directory is built only if you used the --enable-wiki-publisher configure option. Herbert
build --all and clean.
I have made a build --all, after which I use configure to set other options. Now is there any way I can clean all objects etc. from the previous build. I thought build --all --clean would do it, but build does not recognize --clean I cannot find it in wiki. thanks in advance for help. JanI.
Re: File: readme.xrm
As far as I can see on the usage are your assumption correct, and there must be other ways to make different readme text platform dependent. Would it not be ok, to have one readme for all platforms, and in the text mention the specics ? janI On 22 October 2012 13:34, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/21/12 2:16 PM, jan iversen wrote: There is exactly one file with extension .xrm main/read_license_oo/docs/readme/readme.xrm is there a reason (apart from history) for it being in .xrm or could it be converted to e.g. .xhp ? If so we could get rid of one more conversion tool (read: does not need to be converted to new code). I am not sure if xhp would be a good option here. But we can probably switch to something else. Maybe a common readme file that gets extended with platform specific portions from other files. When I remember it correctly the xrm files contains the content for the readme file and depending on the platform different content is extracted from this file. Juergen
Re: Directory main/swext/mediawiki
Now it generates ok, thanks to that little tip.
I have taken the wiki-publisher.oxt file and put it Documents (that where
my extension manager looks).
When I open the oxt file with extension manager, I get a strange error:
(com.sun.star.deployment.DeploymentException) {{Message=Could not obtain
path to license. Possible error in description.xml,
Context=(com.sun.star.uno.Xinterface) @0}, cause=(any) {void}}
description.xml has tag license_test that refers to
xlink:href:licene/LICENSE
The error text seems to come from: desktop/deployment.
Can that be because I have just done a build --all and should have done
with --with-lang ?
thanks in advance.
rgds
Jan I
On 22 October 2012 10:36, Herbert Duerr h...@apache.org wrote:
On 21.10.2012 18:16, jan iversen wrote:
Now I am the one that is confused (again).
Is the directory mediaWiki active or not ?
The extension in that directory is built only if you used the
--enable-wiki-publisher
configure option.
Herbert
Re: File: readme.xrm
+1, That is a very good point !! But may we can still write it as plain text, put some tags in, and use sed to split when generating installation sets ? janI On 22 October 2012 18:00, Keith N. McKenna keith.mcke...@comcast.netwrote: jan iversen wrote: As far as I can see on the usage are your assumption correct, and there must be other ways to make different readme text platform dependent. Would it not be ok, to have one readme for all platforms, and in the text mention the specics ? janI On 22 October 2012 13:34, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/21/12 2:16 PM, jan iversen wrote: There is exactly one file with extension .xrm main/read_license_oo/docs/**readme/readme.xrm is there a reason (apart from history) for it being in .xrm or could it be converted to e.g. .xhp ? If so we could get rid of one more conversion tool (read: does not need to be converted to new code). I am not sure if xhp would be a good option here. But we can probably switch to something else. Maybe a common readme file that gets extended with platform specific portions from other files. When I remember it correctly the xrm files contains the content for the readme file and depending on the platform different content is extracted from this file. Juergen Jan; That may indeed be one way to do it. My concern is that users will get frustrated trying to wade through the info for the other platforms and just not bother with it at all. Of course based on the way they read the release notes they probably don't read it anyway. Be that as it may do we want to give them another reason not to read it and possible miss pertinent information. Regards Keith
Re: AOO volunteers: essential skills and tasks
Sorry, it seemed my remark sparked quite some feelings, that was not my intention ! But not having been on the list for very long, means that there a lot of history I dont have, and the mailer didnt exactly like when I tried to get all messages. During my research for a updated l10n process, I have often heard that has been discussed before, which makes me go search for old mail. In a forum we would have more catagories than just one mailling list, making it easier to find relevant old information. That was all that was in my remark (getting history). Jan. On 21 October 2012 09:50, Fernando Cassia fcas...@gmail.com wrote: On Fri, Oct 19, 2012 at 6:47 PM, jan iversen jancasacon...@gmail.com wrote: 3) +1, but I will never understand why it is a mailing list and not a forum, where it is so much easier to look at history Oh please, not again... mailing lists have many advantages over web forums: 1. Speed (the emails arrive automagically, are text-only -most of the time-), no waiting for forum web pages to load, no adverts, no footers, no colors, no graphical sig files, no animated gifs to look at, no delay to log-in, messages just arrive to your mailbox 2. Easy archival (just set a rule and archive your list email to a given subfolder or a given GMail Label) 3. Reply speed (most of my on-line time is spent loking at the gmail inbox, when something of interest arrives -ie ooo-dev with some interesting subject line- I click and read it immediately). 4. Sense of community: it´s much easier to deal with troublemakers, spammers and trolls etc on a mailing list (just ban his email address) than on web forums. ...and that just are the most obvious ones off the top of my head on a Sunday at 4:50am local time... FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act - George Orwell
proposal for new l10n workflow
I have finally finished my proposal for a new workflow. please have a look at: http://wiki.openoffice.org/wiki/File:L10procNew.pdf I have tried to implement the comments (on the document describing the existing workflow) from the community, and at the same time avoid non-essential themes that seems to open discussions :-) The workflow I have proposed is based on my knowledge from large organizations, so I am sure it can workbut I do not know if the community as such want it. It has advantages for everybody: - developers dont really see a change - our release manager saves a lot of manual work - offline translators become a lot closer connected to the process, without being bugged down with technical details. My shoulders are pretty big, so please give me your opinions and suggestions for improvement (I am here to learn, NOT to educate). Please remember one thing the big silent majority does not count here. I post this mail here to give developers a change to speak their mind, it is also posted on l10n, for the more translators who are of course heavily influenced. Once we have agreed to the content, I will undertake the development, but I do need heavy support from a committer (mostly to commit code and publish php/web pages). happy reading. JanI
Re: Directory main/swext/mediawiki
Now I am the one that is confused (again). Is the directory mediaWiki active or not ? SPI is an interface if I understand it right, and that is hopefully not hidden in the mediawiki directory ? jan On 21 October 2012 17:40, Juergen Schmidt jogischm...@gmail.com wrote: Am Samstag, 20. Oktober 2012 um 23:52 schrieb Alexandro Colorado: On Sat, Oct 20, 2012 at 2:50 PM, jan iversen jancasacon...@gmail.com wrote: I am a bit confused. We have a directory named main/swext/mediawiki. Is that the sun wiki publisher 1.1 or are there 2 different mediawiki export extensions ? I ask because I sun wiki publisher 1.1 installed, but if I change the XLS and rebuilt AOO but it does not seem to have an effect. Yes I think it was started on core, and then sent to a separate extensions. Same thing happened with smarttags IIRC. what do you mean here exactly, it doesn't make sense. Smarttags API (or better the SPI) is available in the core and it is now possible to develop smarttags either in the core or as extension. Juergen Either I make a wrong assumption or life is not so simple as I would it to be :-) thanks in advance. jan. -- Alexandro Colorado PPMC Apache OpenOffice http://es.openoffice.org
Re: Directory main/swext/mediawiki
I have looked for a newer source, since it was moved, but our own extensions has a broken link and sourceForge does not offer any help. Any ideas ?? It is a sun part, so we should have inherited it or not ? jan. On 20 October 2012 23:52, Alexandro Colorado j...@oooes.org wrote: On Sat, Oct 20, 2012 at 2:50 PM, jan iversen jancasacon...@gmail.com wrote: I am a bit confused. We have a directory named main/swext/mediawiki. Is that the sun wiki publisher 1.1 or are there 2 different mediawiki export extensions ? I ask because I sun wiki publisher 1.1 installed, but if I change the XLS and rebuilt AOO but it does not seem to have an effect. Yes I think it was started on core, and then sent to a separate extensions. Same thing happened with smarttags IIRC. Either I make a wrong assumption or life is not so simple as I would it to be :-) thanks in advance. jan. -- Alexandro Colorado PPMC Apache OpenOffice http://es.openoffice.org
Re: proposal for new l10n workflow
On 22 October 2012 00:01, Rob Weir robw...@apache.org wrote: On Sun, Oct 21, 2012 at 12:14 PM, jan iversen jancasacon...@gmail.com wrote: I have finally finished my proposal for a new workflow. please have a look at: http://wiki.openoffice.org/wiki/File:L10procNew.pdf I'll take a closer look, but I did browse it quickly and had one question: Hope you like what you read. Do we know more about what it means to have Pootle access Subversion? Does this need read/write access? If so, what SVN account is it using? Is it using credentials from the current logged in Pootle user? Does it need to store SVN login credentials? According to the home page (I have no personal experience) will pootle use the account you use on pootle Yes it requires read/write access, otherwise you cannot commit your changes, and would again have manual steps. Andrea told me that you might meet the developer 4-5 november. Since Pootle and SVN are both ASF-wide services, managed by the Infrastructure team, we'll need to coordinate this carefully. Security concerns will weigh heavily on what is possible here. I totally agree, but the real question is: how many are using pootle to translate compared to the total number. Everybody have been telling me, that most translation is done offline..so that is where I have put my emphasis. -Rob I have tried to implement the comments (on the document describing the existing workflow) from the community, and at the same time avoid non-essential themes that seems to open discussions :-) The workflow I have proposed is based on my knowledge from large organizations, so I am sure it can workbut I do not know if the community as such want it. It has advantages for everybody: - developers dont really see a change - our release manager saves a lot of manual work - offline translators become a lot closer connected to the process, without being bugged down with technical details. My shoulders are pretty big, so please give me your opinions and suggestions for improvement (I am here to learn, NOT to educate). Please remember one thing the big silent majority does not count here. I post this mail here to give developers a change to speak their mind, it is also posted on l10n, for the more translators who are of course heavily influenced. Once we have agreed to the content, I will undertake the development, but I do need heavy support from a committer (mostly to commit code and publish php/web pages). happy reading. JanI
Re: AOO volunteers: essential skills and tasks
Sorry, I think I was a bit to argumentative last night, I really like your idea I have added a few comments below. jan. On 20 October 2012 00:18, Rob Weir robw...@apache.org wrote: On Fri, Oct 19, 2012 at 5:47 PM, jan iversen jancasacon...@gmail.com wrote: I think it is a good starting point, however I dont like the notation level 1, is looks like a graduation process, and I have to ask myself where am I on that latter. I don't want suggest that everyone must go through these steps. An experienced open source volunteer probably would just skim this material. Someone who is a Committer on another Apache project would probably skip over it altogether. The name Level 1 doesn't matter. We can call it Stage 1, or even Introduction. But there is an explicit ordering, and giving numbers is the natural way to express an ordering. But I am sensitive to having these stages give the feeling of accomplishment without becoming unwelcome status markers. Your list is quite OK, may I suggest calling help to get started, and of course you are right about the numbering, it was the sense of having to cross a bridge that caught me. 1) Introduce yourself (by the way I think I have forgotten that). why do it on the mailling list, when Wiki ask you for more or less the exact same type of information. This is more for the benefit of existing project volunteers already subscribed to ooo-dev. This gives them the opportunity to see who is getting involved. They might recognize some names. If so they can reach out to offer additional help and encouragement. 2) I like that. 3) +1, but I will never understand why it is a mailing list and not a forum, where it is so much easier to look at history Mailing lists are the lowest common denominator technologies. You can access email from nearly any device, online or offline, using plain text. It is important to note that as a project we don't directly control mailing lists, websites, Bugzilla, etc., except at the level of the content and application admin functions. The sysadmin functions are done ASF-wide by a group of volunteers that we call the Apache Infrastructure team. Since they are maintaining services for over 100 projects, there are limits to how much customization each project can have. This is a consideration for maintenance as well as server resources and security. So there is a something like a menu of tools we have access to, and which are supported by the Infra team. But changing the menu is more difficult. 4+5) yes, but that has not much to do specifically with AOO. Right. But these are practical issues that have come up with past volunteers. For any such document we need to assume some initial skill/knowledge level. This means those who have these skills already will find some items unnecessary. This is hard to avoid. 7) the project planning part seems a bit of a contradiction, look at localization planning as an example. Maybe calling it Project Coordination would be more accurate. CWiki is what we've been using to coordinate the various efforts of a major project-wide initiative, like a specific release. For example, we're using a page now to coordinate graduation-related infrastructure changes: https://cwiki.apache.org/confluence/display/OOOUSERS/Graduation+Infrastructure+Changes I think it is wise to have coordination pages, and needed with the number of people involved. Sorry for being frank, I do not want to be non-polite, but a lot of these items just highlight my difficulties. Nothing on this page is going to help with the current localization process. I'm hoping that, with your help, we resolve that in parallel. I know that, I am past most of these items, but they are important for other volunteers, I assume you saw the list I made on l10n, and got one very long reply related to localization. I work quite a lot at the moment to get the proposal finished and the l10n.openoffice.org updated. -Rob All aside, I think we are making huge steps in the right direction and that is what matters jan. On 19 October 2012 22:07, Rob Weir robw...@apache.org wrote: On Fri, Oct 19, 2012 at 12:17 PM, Rob Weir robw...@apache.org wrote: I am thinking about what new project volunteers need to get started. Obviously there are area-specific things. For example, developers need to know how to download and build. Translation volunteers need to understand Pootle, etc. But there are also some basic things that all volunteers should probably do. Although we have all of this information (or at least most of it) on the website or wikis or mailing list archives, it is scattered all over the place. I think it would be good if we could collect this information (or at least links to this information) into one place and put a linear order behind it, a step of specific steps we want new volunteers
Re: AOO volunteers: essential skills and tasks
You are quite right, I might not be the typical volunteer, and it is very important to find a hook where you can start, I had the luck that juergen and andrea gave me a starting point. Your list is quite ok, just lets call it something neutral, like help to get started. jan On 20 October 2012 00:24, Rob Weir robw...@apache.org wrote: On Fri, Oct 19, 2012 at 6:16 PM, jan iversen jancasacon...@gmail.com wrote: I think it is important to remember, that a volunteer is not signing up for anything. A volunteer, in my view, is a person who wants to help with his/hers skillset...so if we start saying you have to pass level x before continuing we have already lost (At least I can relate that to myself) That might be true for you. But I can tell you from experience that we've had volunteer after volunteer who have posted a note to this list, said they wanted to help, stuck around for a few days, and then were never heard of again. They never found a hook that they could attach themselves to. They never figured out how to get started. The couldn't find where to get started. The lack of accomplishment and progress leads to frustration, and then they are gone. Maybe we can find some way of expressing this without offering too much offense ? -Rob I have been in this business since 1975, and I have never made it through any of all these master classes and other exams. I am just one of the guys who get things done, like in the early days before tcp/ip. What I am trying to say is, let´s help people work with usthat´s what it´s all about, if we can help people to easier help us, then we have a win-win situation. And in respect of introducing myself, which I forgot please read this resume: http://wiki.openoffice.org/wiki/User:JanIversen jan. Jan. On 19 October 2012 23:08, Rob Weir rabas...@gmail.com wrote: On Oct 19, 2012, at 4:45 PM, Kay Schenk kay.sch...@gmail.com wrote: On 10/19/2012 01:07 PM, Rob Weir wrote: On Fri, Oct 19, 2012 at 12:17 PM, Rob Weir robw...@apache.org wrote: I am thinking about what new project volunteers need to get started. Obviously there are area-specific things. For example, developers need to know how to download and build. Translation volunteers need to understand Pootle, etc. But there are also some basic things that all volunteers should probably do. Although we have all of this information (or at least most of it) on the website or wikis or mailing list archives, it is scattered all over the place. I think it would be good if we could collect this information (or at least links to this information) into one place and put a linear order behind it, a step of specific steps we want new volunteers to take. Now, I can hear the objections already -- you can't tell volunteers what to do. That is why they are volunteers. You can't regiment them, etc. This is true. But at the scale we need to operate at -- I'm aiming to attract dozens of new volunteers on the project by the end of the year -- we need some structure. So what can we do to make their first 2 weeks in the project easier for them, and easier for us? One idea: Think of the new volunteer startup tasks in terms of stages or levels, a defined set of reading and other activities that leads them to acquire basic skills in our community. For example: To make it more concrete, this is what Level 1 might look like: http://incubator.apache.org/openofficeorg/orientation/level-1.html -Rob This is very good! I esp like the last part about providing a way for volunteers to sign up if you will. This will be a nice touch. I'm also wondering if there's some way to tie this in to our current Help Wanted page: https://cwiki.apache.org/confluence/display/OOOUSERS/Help+Wanted Yes, It is worth looking at the new volunteer view of things, from end to end. My current thinking is this: as we scale the number of volunteers we'll soon want a better way to track items like these. Maybe putting them into BZ would work? Introduce a new field to record difficulty in BZ and filters to list unassigned easy issues? Maybe someone has some ideas? Level 1 tasks: 1) Read the following web pages on the ASF, roles at Apache and the Apache Way 2) Sign up for the following accounts that every volunteer should have: ooo-announce, ooo-dev, ooo-users, MWiki, CWiki, BZ, Forums 3) Read this helpful document on hints for managing your inbox with rules and folders 4) Read this code of conduct page on list etiquette 5) Send a note to ooo-dev list and introduce yourself 6) Edit this wiki page containing project volunteers. Add your name and indicate that you have completed Level 1. Level 2 tasks: 1) Using the Apache CMS in anonymous mode 2) Readings
Re: Need new logo for openoffice.apache.org
I really like the logo on the openOffice.org site, it is (at least to me) more modern and eye-catching. We should only use 1 logo, that is simpler and for the end-user more understandable. Jan. On 20 October 2012 16:28, Rob Weir robw...@apache.org wrote: See upper left here: http://openoffice.apache.org The Incubating is integrated into the graphic. The underlying file is here: a PNG with transparent background. http://incubator.apache.org/openofficeorg/images/300x100_dj_trans.png What do we want to do here? 1) Edit that graphic to remove Incubating? 2) Use a different graphic? Note that the http://www.openoffice.org/ site uses a different form of the branding. Are we intentionally using two different logos here? Do we want to continue this? -Rob
Re: Need new logo for openoffice.apache.org
+1 to consistent branding but I admit I cannot follow the details here it is beyond my scope :-) BUT I trust your suggestions. janI On 20 October 2012 20:21, Rob Weir robw...@apache.org wrote: On Sat, Oct 20, 2012 at 10:49 AM, RGB ES rgb.m...@gmail.com wrote: 2012/10/20 jan iversen jancasacon...@gmail.com I really like the logo on the openOffice.org site, it is (at least to me) more modern and eye-catching. +1 We should only use 1 logo, that is simpler and for the end-user more understandable. +1 too. OK. I changed the openoffice.apache.org website to use the same logo as www.openoffice.org. But I am sympathetic to Alexandro's view that we need across-the-board greater consistency on branding. We'll get there, I think, but it will take time. -Rob Regards Ricardo Jan. On 20 October 2012 16:28, Rob Weir robw...@apache.org wrote: See upper left here: http://openoffice.apache.org The Incubating is integrated into the graphic. The underlying file is here: a PNG with transparent background. http://incubator.apache.org/openofficeorg/images/300x100_dj_trans.png What do we want to do here? 1) Edit that graphic to remove Incubating? 2) Use a different graphic? Note that the http://www.openoffice.org/ site uses a different form of the branding. Are we intentionally using two different logos here? Do we want to continue this? -Rob
Re: Need new logo for openoffice.apache.org
A legal question in that respect of logo, is it legal if I write on my personal blog that I help AOO and use the logo with a link to openoffice.org? Jan. On 20 October 2012 20:49, Alexandro Colorado j...@oooes.org wrote: On Sat, Oct 20, 2012 at 1:21 PM, Rob Weir robw...@apache.org wrote: On Sat, Oct 20, 2012 at 10:49 AM, RGB ES rgb.m...@gmail.com wrote: 2012/10/20 jan iversen jancasacon...@gmail.com I really like the logo on the openOffice.org site, it is (at least to me) more modern and eye-catching. +1 We should only use 1 logo, that is simpler and for the end-user more understandable. +1 too. OK. I changed the openoffice.apache.org website to use the same logo as www.openoffice.org. But I am sympathetic to Alexandro's view that we need across-the-board greater consistency on branding. We'll get there, I think, but it will take time. -Rob Regards Ricardo Jan. On 20 October 2012 16:28, Rob Weir robw...@apache.org wrote: See upper left here: http://openoffice.apache.org The Incubating is integrated into the graphic. The underlying file is here: a PNG with transparent background. http://incubator.apache.org/openofficeorg/images/300x100_dj_trans.png What do we want to do here? 1) Edit that graphic to remove Incubating? 2) Use a different graphic? Note that the http://www.openoffice.org/ site uses a different form of the branding. Are we intentionally using two different logos here? Do we want to continue this? Well most of the artwork is done, is just a matter of doing the commit to the right branch. Linux has png files so they are taken from the site, which also has the .ico and icm for windows and mac. Besides that, I wonder what else would be needed. Example Writer: Linux: http://www.openoffice.org/ui/VisualDesign/gifs/Icons/refresh_icons/pngs/OOo_Writer_48x48.png Windows: http://www.openoffice.org/ui/VisualDesign/gifs/Icons/refresh_icons/icos/OOo_Writer.ico OSX: Not required Mime-type: http://www.openoffice.org/ui/VisualDesign/gifs/Icons/ODF_icons/ODF_textdocument_256x256.png The original discussion on the lack of color of OO3 generated different options which were ignored, should we adopt them now? https://issues.apache.org/ooo/show_bug.cgi?id=112141 There was some icons donated on issuezzilla: https://issues.apache.org/ooo/show_bug.cgi?id=118820 (not impressed) -Rob -- Alexandro Colorado PPMC Apache OpenOffice http://es.openoffice.org
Re: Another logo needs updating: Get it here!
If we want to have the same logo all over, respin I assume would not do the job ? jan. On 20 October 2012 21:23, Rob Weir robw...@apache.org wrote: http://incubator.apache.org/openofficeorg/get-it-here.html This logo has an integrated incubator reference in it as well. I think Drew made the most recent version of this. Anyone have the source, or can easily respin it without the incubator block? Thanks! -Rob
Re: Another logo needs updating: Get it here!
Since it seems allowed, it would be nicer to have the same logo. I understand that we have to consider the legal aspect, but seen purely from a users point of view, one logo means one product. jan. On 20 October 2012 21:56, Rob Weir robw...@apache.org wrote: On Sat, Oct 20, 2012 at 3:40 PM, jan iversen jancasacon...@gmail.com wrote: If we want to have the same logo all over, respin I assume would not do the job ? Sorry for the slang. By respin I meant taking whatever vector source file (SVG, perhaps) that Drew used for that button originally, and then remove the incubator block and regenerate a bitmap for us to put on the website. It was intentional, at least at the time, for the Get it here! graphic to be distinct from the official project logo. This was to avoid diluting the trademark. We wanted the official project logo to be associated with the official website. So if users saw it they knew they were dealing with an official project site. We would then have thematically-related logos that could be used for various affiliate uses, such as on personal websites. That was the purpose of the Get it here! logo. But that was then, this is now. As I understand it now, ASF policy has evolved in this area, and it appears permissible for websites to use logo, provided they follow these rules: http://www.apache.org/foundation/marks/faq/#integrateswith But IMHO, the Get it here! button is still useful, since its size and aspect ratio, as well as the beveling, make it ideal for a download button. -Rob jan. On 20 October 2012 21:23, Rob Weir robw...@apache.org wrote: http://incubator.apache.org/openofficeorg/get-it-here.html This logo has an integrated incubator reference in it as well. I think Drew made the most recent version of this. Anyone have the source, or can easily respin it without the incubator block? Thanks! -Rob
Re: Another logo needs updating: Get it here!
+1 On 20 October 2012 23:09, RGB ES rgb.m...@gmail.com wrote: 2012/10/20 Rob Weir robw...@apache.org On Sat, Oct 20, 2012 at 3:40 PM, jan iversen jancasacon...@gmail.com wrote: If we want to have the same logo all over, respin I assume would not do the job ? Sorry for the slang. By respin I meant taking whatever vector source file (SVG, perhaps) that Drew used for that button originally, and then remove the incubator block and regenerate a bitmap for us to put on the website. It was intentional, at least at the time, for the Get it here! graphic to be distinct from the official project logo. This was to avoid diluting the trademark. We wanted the official project logo to be associated with the official website. So if users saw it they knew they were dealing with an official project site. We would then have thematically-related logos that could be used for various affiliate uses, such as on personal websites. That was the purpose of the Get it here! logo. But that was then, this is now. As I understand it now, ASF policy has evolved in this area, and it appears permissible for websites to use logo, provided they follow these rules: http://www.apache.org/foundation/marks/faq/#integrateswith But IMHO, the Get it here! button is still useful, since its size and aspect ratio, as well as the beveling, make it ideal for a download button. -Rob jan. On 20 October 2012 21:23, Rob Weir robw...@apache.org wrote: http://incubator.apache.org/openofficeorg/get-it-here.html This logo has an integrated incubator reference in it as well. I think Drew made the most recent version of this. Anyone have the source, or can easily respin it without the incubator block? Thanks! -Rob What about the one we use on the forums? http://forum.openoffice.org/es/forum/styles/prosilver/imageset/AOO-download.png It is the same from the web site plus the traditional download arrow on top of the orb. Simple and clear. Regards Ricardo
CMS diff: DA.OpenOffice - En komplet fri kontorpakke
Clone URL (Committers only): https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://ooo-site.apache.org/da%2Findex.html jan iversen Index: trunk/content/da/index.html === --- trunk/content/da/index.html (revision 134) +++ trunk/content/da/index.html (working copy) @@ -1,3 +1,4 @@ +Added danish translation to DA page. !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html lang=da @@ -25,6 +26,37 @@ h2Velkommen til Apache OpenOffice/h2 + h2Apache Open Office er nu et top projekt hos Apache/h2 +Apache software Foundation annoncerer Apache OpenOffice™ som et Top-Niveau Projekt + +Pris vindende førende Open Source produktions pakke bredt brugt i over 228 lande, over 20 millioner download af den seneste version siden maj 2012. + +Forest Hill, MD – 18 Oktober 2012 – Apache Software Foundation (ASF), den udelukkende frivillige udviklere og kuvøser af næsten 150 Open Source projekter og initativer, annoncerede idag at Apache Open Office er overgået fra Apache kuvøse til at blive et Top-Niveau Projekt (TNP), visende at projektets sanfund og produkt er blevet styret godt og korrekt under ASF udvide demokratiske proces og principper. + +Beståelsen er for OpenOffice et bevis på Apache vejens successfulde skalering fra kuvøse til 'indholds branding' til et meget etableret slut-bruger produkt, sagde ASF vice præsidenten og Apache OpenOffice mentor Ross Gardler. Kuvøse processen tillader erfarne Apache bidragsydere at guide projelt, hjælpe både nye og etablerede OpenOffice bidragsydere at bygge et Apache-stil samfund som er både åbent og fordelt. + +OpenOffice beståelsen er den officielle anerkendelse at projektet er nu i stand til at lede sig selv ikke kun i teknisk henseende, men også i samfunds spørgsmål., sagde Andrea Pescetti, vice præsident hos Apache OpenOffice. 'Apache vejen' og den metoder, som f.eks. at tage hver beslutning i offentligheden med total gennemsigtighed, har tilladt projektet at tiltrække og engagere nye frivillige, og til at vælge og fordele Projekt Ledelses Kommitteen som vil garantere en stabil fremtid for Apache OpenOffice. + +Indledningsvis lavet af Star Division in the 1990's, blev OpenOffice code basen købt af Sun Microsystems in 1999 og senere Oracle Corporation in 2010, inden den blev sendt til The Apache Software Foundation kuvøse i Juni 2011. + +Under udviklings perioden i Apache kuvøsen, har Apache OpenOffice projektet overflyttet næsten 10 million kode linier, tilført utallige udvidelser, og fikset dusinvis af bruger-rapporterede fejl i den populære og gratis produktions pakke. Som tilføjelse, har softwaren modtaget 5 industri priser, rangerende fra individuelle komponent top punkter over top downloading til den bedste open source produktions pakke. + +I Maj 2012 blev Apache OpenOffice v3.4 offentliggjort på 20 sprog (redaktør: den danske er ved kvalitetstesten), og downloaded mere end 20 millioner gange af enkelt personer, firmaer, skoler og statslige institutioner i over 228 lande. Siden det, har projektet arbejdet på nye funktioner, innovationer og releases målsat til først og fjerde kvartal 2013. + +It's really cool at OpenOffice er nu et top-niveau projekt hos Apache, siger Juergen Schmidt, Apache OpenOffice Release Chef. Vi har mødt mange milepæle for at nå denne milepæl: vores første OpenOffice 3.4 release krævede af samfundet ikke bare flytning af koden fra Oracle til apache, men også at udskifte ugyldigt licenserede biblioteker for succesfuldt at møde Apache licens krav. Nu er vores Apache OpenOffice kilde code frit tilgængeligt for projekter og organisationer. + +Vi er meget stolte af denne vigtige milepæl og byder OpenOffice velkommen i vores fold af verdens ledende Apache projekter, tilføjer Gardler. + +Tilgængelighed og Styring +Apache OpenOffice er tilgængelig gratis for enhver bruger og formål, og kan downloades fra http://openoffice.org. Productet downloades et ubegrænset antal gange på¨PC for et ubegrænset antal af brugere - HELT GRATIS fri for alle licens afgifter. Projektet har en stærk fokusering på at støtte open standards, fra ODF (der først implementerede ISO/IEC 26300) til fremtidige planer for CMIS, OpenSocial, og OData. + +Som med al Apache software, er Apache OpenOffice software released under Apache Licens v2.0, og bliver kontrolleret af et selv valgt team af aktive bidragsydere til projektet. En Projekt Ledelses Kommitte (PLK) guidesr Projektets dag-til-dag opgaver, inklusive samfunds udvikling og produkt releases. Information om Apache OpenOffice kilde dode, dokumentation, e-mail lister, dettilhørende resourcer, og veje til at deltage er tilgængelige på http://openoffice.apache.org/. + +Om Apache Software Foundation (ASF) +Etableret i 1999, en helt frivilligt fundament kontrollerer næsten femhundrede ledende Open Source projekter, inklusive
Re: [WWW]: shared ideas and looking for feedback
It would be a good idea to have the same structure and then one directory with country special parts...as you say it makes it easier to maintain, and with the extra directory nobody is limited. jan On 19 October 2012 10:22, Jürgen Schmidt jogischm...@gmail.com wrote: Hi, yesterday I had problems to find a good place for the German translation of the graduation press release. And I thought that it is probably a good idea to cleanup the whole page with a clear and well defined structure. I know that there is work ongoing and that we move already in this direction. But nevertheless I would like to share the things I have in mind to check if it is aligned with the already ongoing work or if it makes sense at all. 1. a clear structure for the English content as well as the translated pages. .../index.hmtl .../de/index.html .../it/index.html ... .../press/msg_20121019.html .../de/press/msg_20121019.html .../it/press/msg_20121019.html ... Means we have for all pages a translated version in the related sub directory. Same path and same name only the content is translated. This makes it easy to find the related translation for any files. We can also use Pootle to do the translation of the web content in the future. 2. we have special news areas where local communities can spread further news relevant to their local activities, e.g. local conferences, events. But in general we have the same content on all pages. Other local community relevant content should be moved in the wiki. The main idea is to have a smaller but cleaner and well structured and organized user portal www.openoffice.org. Community internal things should be move on openoffice.apache.org or the wiki. I know it is not really new and it is probably more to remind myself but I am interested to hear others opinion. Regards Juergen
Re: CMS diff: DA.OpenOffice - En komplet fri kontorpakke
Hi Rob I just followed your youtube video :-) and CMS sent this off, more or less automatically. I think it is actually a diff to the existing page, and I thought your idea was quite brilliant since it would allow me and others to update the content easily. How are the others doing it, do they have commit rights ? rgds jan I. 2012/10/19 Rob Weir robw...@apache.org This won't work. The existing page is HTML, so the additional text needs to be in HTML as well, including p for paragraphs and a href for hyperlinks, etc. One idea to simplify it would be to have only a tease of the story, maybe a sentence or two, and then link to this page for the full story: http://www.openoffice.org/da/graduation.html -Rob 2012/10/19 jan iversen anonym...@apache.org: Clone URL (Committers only): https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://ooo-site.apache.org/da%2Findex.html jan iversen Index: trunk/content/da/index.html === --- trunk/content/da/index.html (revision 134) +++ trunk/content/da/index.html (working copy) @@ -1,3 +1,4 @@ +Added danish translation to DA page. !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html lang=da @@ -25,6 +26,37 @@ h2Velkommen til Apache OpenOffice/h2 + h2Apache Open Office er nu et top projekt hos Apache/h2 +Apache software Foundation annoncerer Apache OpenOffice™ som et Top-Niveau Projekt + +Pris vindende førende Open Source produktions pakke bredt brugt i over 228 lande, over 20 millioner download af den seneste version siden maj 2012. + +Forest Hill, MD – 18 Oktober 2012 – Apache Software Foundation (ASF), den udelukkende frivillige udviklere og kuvøser af næsten 150 Open Source projekter og initativer, annoncerede idag at Apache Open Office er overgået fra Apache kuvøse til at blive et Top-Niveau Projekt (TNP), visende at projektets sanfund og produkt er blevet styret godt og korrekt under ASF udvide demokratiske proces og principper. + +Beståelsen er for OpenOffice et bevis på Apache vejens successfulde skalering fra kuvøse til 'indholds branding' til et meget etableret slut-bruger produkt, sagde ASF vice præsidenten og Apache OpenOffice mentor Ross Gardler. Kuvøse processen tillader erfarne Apache bidragsydere at guide projelt, hjælpe både nye og etablerede OpenOffice bidragsydere at bygge et Apache-stil samfund som er både åbent og fordelt. + +OpenOffice beståelsen er den officielle anerkendelse at projektet er nu i stand til at lede sig selv ikke kun i teknisk henseende, men også i samfunds spørgsmål., sagde Andrea Pescetti, vice præsident hos Apache OpenOffice. 'Apache vejen' og den metoder, som f.eks. at tage hver beslutning i offentligheden med total gennemsigtighed, har tilladt projektet at tiltrække og engagere nye frivillige, og til at vælge og fordele Projekt Ledelses Kommitteen som vil garantere en stabil fremtid for Apache OpenOffice. + +Indledningsvis lavet af Star Division in the 1990's, blev OpenOffice code basen købt af Sun Microsystems in 1999 og senere Oracle Corporation in 2010, inden den blev sendt til The Apache Software Foundation kuvøse i Juni 2011. + +Under udviklings perioden i Apache kuvøsen, har Apache OpenOffice projektet overflyttet næsten 10 million kode linier, tilført utallige udvidelser, og fikset dusinvis af bruger-rapporterede fejl i den populære og gratis produktions pakke. Som tilføjelse, har softwaren modtaget 5 industri priser, rangerende fra individuelle komponent top punkter over top downloading til den bedste open source produktions pakke. + +I Maj 2012 blev Apache OpenOffice v3.4 offentliggjort på 20 sprog (redaktør: den danske er ved kvalitetstesten), og downloaded mere end 20 millioner gange af enkelt personer, firmaer, skoler og statslige institutioner i over 228 lande. Siden det, har projektet arbejdet på nye funktioner, innovationer og releases målsat til først og fjerde kvartal 2013. + +It's really cool at OpenOffice er nu et top-niveau projekt hos Apache, siger Juergen Schmidt, Apache OpenOffice Release Chef. Vi har mødt mange milepæle for at nå denne milepæl: vores første OpenOffice 3.4 release krævede af samfundet ikke bare flytning af koden fra Oracle til apache, men også at udskifte ugyldigt licenserede biblioteker for succesfuldt at møde Apache licens krav. Nu er vores Apache OpenOffice kilde code frit tilgængeligt for projekter og organisationer. + +Vi er meget stolte af denne vigtige milepæl og byder OpenOffice velkommen i vores fold af verdens ledende Apache projekter, tilføjer Gardler. + +Tilgængelighed og Styring +Apache OpenOffice er tilgængelig gratis for enhver bruger og formål, og kan downloades fra http://openoffice.org. Productet downloades et ubegrænset antal gange på¨PC for et ubegrænset antal af brugere
Re: [WWW]: shared ideas and looking for feedback
If pootle used SVN, you would at least have it in SVN automatically :-) jan. On 19 October 2012 13:51, Rob Weir robw...@apache.org wrote: On Fri, Oct 19, 2012 at 4:22 AM, Jürgen Schmidt jogischm...@gmail.com wrote: Hi, yesterday I had problems to find a good place for the German translation of the graduation press release. And I thought that it is probably a good idea to cleanup the whole page with a clear and well defined structure. I know that there is work ongoing and that we move already in this direction. But nevertheless I would like to share the things I have in mind to check if it is aligned with the already ongoing work or if it makes sense at all. 1. a clear structure for the English content as well as the translated pages. .../index.hmtl .../de/index.html .../it/index.html ... .../press/msg_20121019.html .../de/press/msg_20121019.html .../it/press/msg_20121019.html ... Means we have for all pages a translated version in the related sub directory. Same path and same name only the content is translated. This makes it easy to find the related translation for any files. We can also use Pootle to do the translation of the web content in the future. 2. we have special news areas where local communities can spread further news relevant to their local activities, e.g. local conferences, events. But in general we have the same content on all pages. Other local community relevant content should be moved in the wiki. The main idea is to have a smaller but cleaner and well structured and organized user portal www.openoffice.org. Community internal things should be move on openoffice.apache.org or the wiki. I know it is not really new and it is probably more to remind myself but I am interested to hear others opinion. This has certainly been discussed: enforce the same template for NL pages, same look and feel, same base content. But then have a portion of the page be reserved for locale-specific concerns. For example, the Arabic page has a link to Bidi specific issue. Or you might have a locale event or news story. We almost do this today for some languages, but this was based on a one-time copy of the English website. Once the copy is made the sites diverge over time. Truly using a single template, with strings resourced in Pootle, would be ideal. But do you see us integrating with Pootle in a way that allows us to update a webpage without requiring manual steps to extract Pootle resources and bring them into SVN and converted to HTML? This would really need to be automated to work for us. -Rob Regards Juergen
Re: CMS diff: DA.OpenOffice - En komplet fri kontorpakke
Got it, my failure (it was obvious a bit too late when I made it) I will do a new CMS session after lunch. It seems that mdtext is just an abbreviation of mediaWiki, would life be easy if the gurus of all these different forms could get together and decide on something common. Maybe for us (in the long term) we could simplify thing and e.g. say we use mediaWiki. jan. 2012/10/19 Rob Weir robw...@apache.org 2012/10/19 jan iversen jancasacon...@gmail.com: Hi Rob I just followed your youtube video :-) and CMS sent this off, more or less automatically. One thing I didn't mention in the video is we have two main kinds of pages on the website: HTML and mdtext. HTML is HTML, of course. mdtext == Markdown Text, a simplified format that is really easy for simple informational pages with text and headers, lists and hyperlinks. You can read about the syntax here: http://daringfireball.net/projects/markdown/ Or even better, look at a sample page in source: https://svn.apache.org/repos/asf/incubator/ooo/site/trunk/content/openofficeorg/native-lang.mdtext I think it is actually a diff to the existing page, and I thought your idea was quite brilliant since it would allow me and others to update the content easily. You figured out the web CMS interface, which is a stumbling block for many people. So this is a great start, I think. How are the others doing it, do they have commit rights ? If I'm editing a page or two, I use the same web interface. So what you did was right, except in the syntax. A specific example. You added: +Tilgængelighed og Styring +Apache OpenOffice er tilgængelig gratis for enhver bruger og formål, og kan downloades fra http://openoffice.org. Productet downloades et ubegrænset antal gange på¨PC for et ubegrænset antal af brugere - HELT GRATIS fri for alle licens afgifter. Projektet har en stærk fokusering på at støtte open standards, fra ODF (der først implementerede ISO/IEC 26300) til fremtidige planer for CMIS, OpenSocial, og OData. But what is really needed is HTML markup, like this: h2Tilgængelighed og Styring/h2 p Apache OpenOffice er tilgængelig gratis for enhver bruger og formål, og kan downloades fra a href=http://openoffice.org;http://openoffice.org/a. Productet downloades et ubegrænset antal gange på¨PC for et ubegrænset antal af brugere - HELT GRATIS fri for alle licens afgifter. Projektet har en stærk fokusering på at støtte open standards, fra ODF (der først implementerede ISO/IEC 26300) til fremtidige planer for CMIS, OpenSocial, og OData. /p Does this make sense? You want the diff's to be HTML format as well. The difference for a Committer is they can then check in directly from the web interface, preview how it looks on our staging server, and then publish. Once a page is checked in then the template is applied. Mdtext is converted to HTML, and the HTML is inserted into the skeleton of the template, with standard navigation, headers, footers and other page elements applied. So when you think of a page, concentrate on the content. The rest will come from the template. Regards, -Rob rgds jan I. 2012/10/19 Rob Weir robw...@apache.org This won't work. The existing page is HTML, so the additional text needs to be in HTML as well, including p for paragraphs and a href for hyperlinks, etc. One idea to simplify it would be to have only a tease of the story, maybe a sentence or two, and then link to this page for the full story: http://www.openoffice.org/da/graduation.html -Rob 2012/10/19 jan iversen anonym...@apache.org: Clone URL (Committers only): https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://ooo-site.apache.org/da%2Findex.html jan iversen Index: trunk/content/da/index.html === --- trunk/content/da/index.html (revision 134) +++ trunk/content/da/index.html (working copy) @@ -1,3 +1,4 @@ +Added danish translation to DA page. !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html lang=da @@ -25,6 +26,37 @@ h2Velkommen til Apache OpenOffice/h2 + h2Apache Open Office er nu et top projekt hos Apache/h2 +Apache software Foundation annoncerer Apache OpenOffice™ som et Top-Niveau Projekt + +Pris vindende førende Open Source produktions pakke bredt brugt i over 228 lande, over 20 millioner download af den seneste version siden maj 2012. + +Forest Hill, MD – 18 Oktober 2012 – Apache Software Foundation (ASF), den udelukkende frivillige udviklere og kuvøser af næsten 150 Open Source projekter og initativer, annoncerede idag at Apache Open Office er overgået fra Apache kuvøse til at blive et Top-Niveau Projekt (TNP), visende at projektets sanfund og produkt er blevet styret godt og korrekt under ASF udvide
