Re: Re: Problems with merging the UOF v2.0 source code
Thanks Tsutomu. I can reproduce it on both OO3.4 beta and AOO 3.4. This should be issue 118057, caused by CWS sw34bf03 as mentioned in that issue. The orignal patch in it can fix this issue but the patch has two little format problems. So I attached a new one. Verified on my PC, with that patch, both MS Word 2003 XML import and export filter can work. 2012/6/18 Tsutomu Uchino hanya.r...@gmail.com Hi, 2012/6/18 hongyun.an hongyun...@cs2c.com.cn: yes,I can see the settings,but when I click the save,it gives a window saying Error saving the document Title:Write Error.The file could not be written. My environment is Windows XP 32bit. I got the same error on Xubuntu 32bit. But XHTML filter works. I found these issues for Word 2003 XML filter on 3.4: 118057 [filter] word 2003 XML (wordml) filters broken https://issues.apache.org/ooo/show_bug.cgi?id=118057 119255 Export to Microsoft Word 2003 XML broken https://issues.apache.org/ooo/show_bug.cgi?id=119255 -- hongyun.an I can find the option on my Windows 7 32bit with AOO3.4 New a Writer document, then select menu-File-Save as. And in Option list on the File dialog, Microsoft Word 2003 XML item can be found. Maybe something is different on your environment. Can you see the Microsoft Word 2003 XML option from menu-Tools-XML Filter Settings ? 2012/6/18 hongyun.an hongyun...@cs2c.com.cn hello everyone: Now I am merging the UOF v2.0 source code to the Aoo3.4. But I have found that Aoo340(Build 9588)-new can not save as the XML format,such as the Microsoft Word 2003 XML.Could anybody tell me why it is deleted? The UOF v2.0 source code is based on the XML format.So it will take some time to complete the work. Best wishes. -- hongyun.an -Tsutomu
Re: [Call-for-Review] Issue 56806 WW: page background graphic lost on export
I will take care of this. On Fri, Jun 15, 2012 at 9:36 PM, ZuoJun Chen zjchen...@gmail.com wrote: Hi all, I have a fix to for bug 56806, please review the patch attached to: https://issues.apache.org/ooo/show_bug.cgi?id=56806 I'd like to introduce myself here. I'm a developer and actually use AOO in my daily work to handle a large number of odt and MS Word documents. So I have interesting in interoperability between the Apache Open Office and Microsoft Office, especially in word processor filter and common MS filter. Recently I would like to loot at some issues for ww8filter. Regards - Zuojun
Public query: FixesReady
Hi all, I created a public query[1] in bugzilla which can query out all opened bug with patch available. If you want to review any fix pls start from here. [1] https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=runnamedcmd=FixesReadysharer_id=248432 Thanks Best Regards, Yan Ji
Re: [Call-For-Review] Fix for i119652 - [From Symphony]When press Ctrl+Shift+Backspace in table cell A1 ,Undo,crash
Hi Lin, Please describe the root cause more clearly...And if solution description can be added,that will be better.thanks. On Mon, Jun 11, 2012 at 4:53 PM, lin yuan yuanlin@gmail.com wrote: I have submit a patch to fix issue i119652. It's a crash issue if user use Ctrl+Shift+Backspace to delete a paragraph in the first cell in a table and then do undo action. Detail info and comments of this issue please refer to https://issues.apache.org/ooo/show_bug.cgi?id=119652 Patch info please refer to https://issues.apache.org/ooo/attachment.cgi?id=78230 Please help review this fix. Thanks. Thanks, Lin Yuan -- Best Regards,Jianhong Cheng
Re: [RELEASE][3.4.1]: Include only one en-US dictionary extension
On 19.06.2012 05:07, Ariel Constenla-Haile wrote: Hi there, there have been some reports of users complaining that the Thesaurus does not work. The root of the issue is in the dictionary extensions we are shipping: two of them collide due to lack of uniqueness in the configuration node name, namely dict-en.oxt (the generic EN dictionary) and dict-en-nz-2008-12-03.oxt. The conflict happens on the Thesaurus node: * dict-en.oxt: node oor:name=ThesDic_en-US oor:op=fuse prop oor:name=Locations oor:type=oor:string-list value%origin%/th_en_US_v2.dat/value /prop prop oor:name=Format oor:type=xs:string valueDICT_THES/value /prop prop oor:name=Locales oor:type=oor:string-list valueen-GB en-US en-ZA en-AU en-CA/value /prop /node * dict-en-nz-2008-12-03.oxt: node oor:name=ThesDic_en-US oor:op=fuse prop oor:name=Locations oor:type=oor:string-list value%origin%/th_en_US_v2.dat/value /prop prop oor:name=Format oor:type=xs:string valueDICT_THES/value /prop prop oor:name=Locales oor:type=oor:string-list valueen-NZ/value /prop /node As you see, they have the same name, ThesDic_en-US, despite the fact that the official documentation states clearly that dictionary extension developers should use a unique node name, see http://wiki.services.openoffice.org/wiki/Extension_Dictionaries#Dictionary_entries_.28must_be_provided.29 specially About node names for the dictionaries. The thesaurus file in dict-en-au-2008-12-15 did rename the thesaurus file to th_en_AU_v2.dat. That avoids the conflict but still wastes 18MB of disk space. I didn't research what the fuse operation is *supposed* to do there (it's applied to the node, not to the properties), but the documentation is clear in stating that the node name must be unique. And the result is that the properties are not fused but replaced, having as effect that the en-NZ dictionary installed disables the thesaurus for en-US. As this bug has its root in the dictionary extensions, the only thing we can do to fix it is just provide only one extension, in this case dict-en.oxt. Dropping the other english dictionaries is a good idea for other reasons, too. Issue 119272 (https://issues.apache.org/ooo/show_bug.cgi?id=119272) describes the problem of all dictionaries using more than 160MB, most of this are the large thesaurus files. Including only one english dictionary would reduce this number considerably. Besides, it contains support for most variants of English anyway. -Andre Note that I only discovered this bug in the English dictionary extensions, I didn't check other languages, but we should do so in the cases where we're providing more than one dictionary extension. Regards
Re: OS/2 clipboard implementation not loaded
Seems my guess is not enough but I have no more idea. Maybe we can add logs to some key functions or debug them to get more info. As on Windows, In vcl\source\window\window.cxx(8651) in function Window::GetClipboard(), it will call to create service com.sun.star.datatransfer.clipboard.SystemClipboard . In stoc\source\loader\dllcomponentloader.cxx(223) in function DllComponentLoader::activate(), it will load dll according to rLibName. In dtrans\source\win32\clipb\wcbentry.cxx(105) in function component_getFactory(), it will create the real service according to the pImplName. So if we know if those functions is called we may know which part have issue. 2012/6/19 Yuri Dario mc6...@mclink.it Hi Lin, For a quick check if this is the real root cause, just change dtrans\source\os2\clipb\Os2Clipboard.hxx(43) from #define OS2_CLIPBOARD_IMPL_NAME com.sun.star.datatransfer.clipboard.Os2Clipboard to #define OS2_CLIPBOARD_IMPL_NAME com.sun.star.datatransfer.clipboard.ClipboardW32 this had been already done, but it is not enough. other ideas? thanks! -- Bye, Yuri Dario /* * OS/2 open source software * http://web.os2power.com/yuri * http://www.netlabs.org */
Re: [DISCUSS]Next steps for automated testing
I 2012/6/19 Andrew Rist andrew.r...@oracle.com: On 6/14/2012 11:31 PM, Zhe Liu wrote: Hi all, As mentioned before, I was working on a Java library to perform gui testing. Actually it has been implemented on Symphony source code. It involves 3 modules: 1. https://svn-master.apache.org/repos/test/danielsh/symphony-import/symphony/trunk/main/test It contains all testing scripts. Some JUnit testcases have been written in the package testcase. Smoke testing is re-implemented based on the lib. We also developed some performance testing script, but not include in svn. 2. https://svn-master.apache.org/repos/test/danielsh/symphony-import/symphony/trunk/main/testcommon It contains the low-level implementation to do GUI testing. 3. https://svn-master.apache.org/repos/test/danielsh/symphony-import/symphony/trunk/main/testgui It contains the common utilities used by uno api testing and GUI testing. I also wrote one wiki page to introduce it. http://wiki.services.openoffice.org/wiki/QA/vclauto I propose to do the following tasks next. 1. Migrate the library to our AOO trunk. I has successfully used it to test AOO 3.4 with some patch. symphony/trunk/main/testcommon-ooo/trunk/main/testcommon symphony/trunk/main/testgui-ooo/trunk/main/testgui symphony/trunk/main/test-ooo/trunk/main/test or ooo/trunk/main/testoo (Avoid to conflict with the test module that already exists in AOO) 2. Setup several testing machines to do build verification testing on daily build. Post the result on somewhere(e.g. wiki, or maillist) . The testing platforms includes: Windows XP Windows 7 32b/64b Mac os x Redhat Suse Ubuntu ...? (pls suggest) What are the requirements for these tests? What type of machines? What software needs to be loaded? Require to install JDK 1.6, Ant 1.8.2+, JUnit 4.10+. Testing machines need enable graphics interface. Testing can't be performed in headless mode. How long does it take? What do the scripts look like that kick off the testing? The default test suite takes about 1 hours. We can change test suite size. To start testing, only one command is required. cd testscript ant I has attached testing code to https://issues.apache.org/ooo/show_bug.cgi?id=119998 More detail guide has been updated in wiki http://wiki.services.openoffice.org/wiki/QA/vclauto What is the output of the testing (single file? logs? web pages?)? All of logs, HTML and XML are generated. Generally we only need to check HTML output. Let's figure out what we need to put this on the buildbots... A. 3. Continue to clean up the UNO API testing. I tried to run it and found there are too many failures and some errors. I think API testing is very valuable.Ｉt is essential to revive it. Welcome to comment. -- Andrew Rist | Interoperability Architect OracleCorporate Architecture Group Redwood Shores, CA | 650.506.9847 -- Best Regards From aliu...@gmail.com
Re: [Call-For-Review] Fix for i119652 - [From Symphony]When press Ctrl+Shift+Backspace in table cell A1 ,Undo,crash
Thanks for the advice. I added more detail description about root cause and resolution. 2012/6/19 chengjh chen...@apache.org Hi Lin, Please describe the root cause more clearly...And if solution description can be added,that will be better.thanks. On Mon, Jun 11, 2012 at 4:53 PM, lin yuan yuanlin@gmail.com wrote: I have submit a patch to fix issue i119652. It's a crash issue if user use Ctrl+Shift+Backspace to delete a paragraph in the first cell in a table and then do undo action. Detail info and comments of this issue please refer to https://issues.apache.org/ooo/show_bug.cgi?id=119652 Patch info please refer to https://issues.apache.org/ooo/attachment.cgi?id=78230 Please help review this fix. Thanks. Thanks, Lin Yuan -- Best Regards,Jianhong Cheng
Re: [DISCUSS]Next steps for automated testing
Am 19.06.12 09:29, schrieb Zhe Liu: I 2012/6/19 Andrew Rist andrew.r...@oracle.com: On 6/14/2012 11:31 PM, Zhe Liu wrote: Hi all, As mentioned before, I was working on a Java library to perform gui testing. Actually it has been implemented on Symphony source code. It involves 3 modules: 1. https://svn-master.apache.org/repos/test/danielsh/symphony-import/symphony/trunk/main/test It contains all testing scripts. Some JUnit testcases have been written in the package testcase. Smoke testing is re-implemented based on the lib. We also developed some performance testing script, but not include in svn. 2. https://svn-master.apache.org/repos/test/danielsh/symphony-import/symphony/trunk/main/testcommon It contains the low-level implementation to do GUI testing. 3. https://svn-master.apache.org/repos/test/danielsh/symphony-import/symphony/trunk/main/testgui It contains the common utilities used by uno api testing and GUI testing. I also wrote one wiki page to introduce it. http://wiki.services.openoffice.org/wiki/QA/vclauto I propose to do the following tasks next. 1. Migrate the library to our AOO trunk. I has successfully used it to test AOO 3.4 with some patch. symphony/trunk/main/testcommon-ooo/trunk/main/testcommon symphony/trunk/main/testgui-ooo/trunk/main/testgui symphony/trunk/main/test-ooo/trunk/main/test or ooo/trunk/main/testoo (Avoid to conflict with the test module that already exists in AOO) 2. Setup several testing machines to do build verification testing on daily build. Post the result on somewhere(e.g. wiki, or maillist) . The testing platforms includes: Windows XP Windows 7 32b/64b Mac os x Redhat Suse Ubuntu ...? (pls suggest) What are the requirements for these tests? What type of machines? What software needs to be loaded? Require to install JDK 1.6, Ant 1.8.2+, JUnit 4.10+. Testing machines need enable graphics interface. Testing can't be performed in headless mode. How long does it take? What do the scripts look like that kick off the testing? The default test suite takes about 1 hours. We can change test suite size. To start testing, only one command is required. cd testscript ant I has attached testing code to https://issues.apache.org/ooo/show_bug.cgi?id=119998 More detail guide has been updated in wiki http://wiki.services.openoffice.org/wiki/QA/vclauto What is the output of the testing (single file? logs? web pages?)? All of logs, HTML and XML are generated. Generally we only need to check HTML output. I will try to run this on a Windows 7 VM Greetings Raphael
Re: [RELEASE][3.4.1]: proposing Bug 119400 - Undo broken in several contexts (Basic Editor, Math Editor, Calc Input Line, MultiLine controls, etc) as release blocker
Hi, On 15.06.2012 09:02, Oliver-Rainer Wittmann wrote: Hi, I second the request that issue 119400 [1] should be solved for AOO 3.4.1 It is a regression in AOO 3.4. A patch to fix this issue is already available - thx to hanya hanya.r...@gmail.com I have reviewed the patch - it looks good. Any objections to mark this issue as a release blocker for AOO 3.4.1? [1] https://issues.apache.org/ooo/show_bug.cgi?id=119400 I have seen no objections. In the meanwhile the issue has been fixed, also in branch AOO34. Please grant the 3.4.1 release blocker flag. Thx in advance, Oliver.
Re: OS/2 clipboard implementation not loaded
Hi, As on Windows, In vcl\source\window\window.cxx(8651) in function Window::GetClipboard(), it will call to create service com.sun.star.datatransfer.clipboard.SystemClipboard . I started debugging this call to see why it fails. In stoc\source\loader\dllcomponentloader.cxx(223) in function DllComponentLoader::activate(), it will load dll according to rLibName. In dtrans\source\win32\clipb\wcbentry.cxx(105) in function component_getFactory(), it will create the real service according to the pImplName. I will look at these too, but I think the DLL must be loaded to be able to create the real service. thanks! -- Bye, Yuri Dario /* * OS/2 open source software * http://web.os2power.com/yuri * http://www.netlabs.org */
Re: [RELEASE][3.4.1]: Include only one en-US dictionary extension
On 6/19/12 9:17 AM, Andre Fischer wrote: On 19.06.2012 05:07, Ariel Constenla-Haile wrote: Hi there, there have been some reports of users complaining that the Thesaurus does not work. The root of the issue is in the dictionary extensions we are shipping: two of them collide due to lack of uniqueness in the configuration node name, namely dict-en.oxt (the generic EN dictionary) and dict-en-nz-2008-12-03.oxt. The conflict happens on the Thesaurus node: * dict-en.oxt: node oor:name=ThesDic_en-US oor:op=fuse prop oor:name=Locations oor:type=oor:string-list value%origin%/th_en_US_v2.dat/value /prop prop oor:name=Format oor:type=xs:string valueDICT_THES/value /prop prop oor:name=Locales oor:type=oor:string-list valueen-GB en-US en-ZA en-AU en-CA/value /prop /node * dict-en-nz-2008-12-03.oxt: node oor:name=ThesDic_en-US oor:op=fuse prop oor:name=Locations oor:type=oor:string-list value%origin%/th_en_US_v2.dat/value /prop prop oor:name=Format oor:type=xs:string valueDICT_THES/value /prop prop oor:name=Locales oor:type=oor:string-list valueen-NZ/value /prop /node As you see, they have the same name, ThesDic_en-US, despite the fact that the official documentation states clearly that dictionary extension developers should use a unique node name, see http://wiki.services.openoffice.org/wiki/Extension_Dictionaries#Dictionary_entries_.28must_be_provided.29 specially About node names for the dictionaries. The thesaurus file in dict-en-au-2008-12-15 did rename the thesaurus file to th_en_AU_v2.dat. That avoids the conflict but still wastes 18MB of disk space. I didn't research what the fuse operation is *supposed* to do there (it's applied to the node, not to the properties), but the documentation is clear in stating that the node name must be unique. And the result is that the properties are not fused but replaced, having as effect that the en-NZ dictionary installed disables the thesaurus for en-US. As this bug has its root in the dictionary extensions, the only thing we can do to fix it is just provide only one extension, in this case dict-en.oxt. Dropping the other english dictionaries is a good idea for other reasons, too. Issue 119272 (https://issues.apache.org/ooo/show_bug.cgi?id=119272) describes the problem of all dictionaries using more than 160MB, most of this are the large thesaurus files. Including only one english dictionary would reduce this number considerably. Besides, it contains support for most variants of English anyway. +1 for reducing the number of en dictionaries. Please propose a related issue for 3.4.1 that we can track it. Please no commits on AOO34 without a 3.4.1 issue! Juergen -Andre Note that I only discovered this bug in the English dictionary extensions, I didn't check other languages, but we should do so in the cases where we're providing more than one dictionary extension. Regards
Re: Public query: FixesReady
On 6/19/12 11:22 AM, dongjun zong wrote: Greate. Thanks for sharing. good query but we have to be careful and shouldn't apply these patches out of the box. Many of them are very old and needs further review. If you don't understand the patch or the underlying code I think it won't be a good idea to apply any patch. Don't get me wrong it's a good idea to work on issues which contains patches (especially newer ones which contains bug docs and detailed explanations how to reproduce the problem etc.). Juergen 2012/6/19 Yan Ji yanji...@gmail.com Hi all, I created a public query[1] in bugzilla which can query out all opened bug with patch available. If you want to review any fix pls start from here. [1] https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=runnamedcmd=FixesReadysharer_id=248432 Thanks Best Regards, Yan Ji
[RELEASE][3.4.1][DEV-BUILD]: propose first dev snapshot build for AOO 3.4.1 based on revision 1351633
Hi, I would like to propose that we prepare the first set of dev snapshots for AOO 3.4.1 based on the revision r1351633. We will start from now on to build and provide a dev snapshot every week for testing purposes. We can include Finnish and British English already because I have update both languages ones for testing. Languages for now: en-US ar cs de en-GB es fi fr gl hu it ja nl ru pt-BR zh-CN zh-TW Further languages can be included and the dead line is still end of June as proposed in my initial plan. I am trying to work on all requests for further languages, please send me a reminder if I have forget a language or if I have forgot to send you the po files. The builds will be made available under https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Unofficial+Developer+Snapshots Juergen
Re: [RELEASE][3.4.1][DEV-BUILD]: propose first dev snapshot build for AOO 3.4.1 based on revision 1351633
2012/6/19 Jürgen Schmidt jogischm...@googlemail.com: Hi, I would like to propose that we prepare the first set of dev snapshots for AOO 3.4.1 based on the revision r1351633. We will start from now on to build and provide a dev snapshot every week for testing purposes. We can include Finnish and British English already because I have update both languages ones for testing. Languages for now: en-US ar cs de en-GB es fi fr gl hu it ja nl ru pt-BR zh-CN zh-TW Further languages can be included and the dead line is still end of June as proposed in my initial plan. I am trying to work on all requests for further languages, please send me a reminder if I have forget a language or if I have forgot to send you the po files. The builds will be made available under https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Unofficial+Developer+Snapshots Juergen Good! Which translation files will be included on this build? On last days I made lots of changes on pootle for ES locale and I would like to test the new translation. Regards Ricardo
Re: [RELEASE][3.4.1][DEV-BUILD]: propose first dev snapshot build for AOO 3.4.1 based on revision 1351633
On 6/19/12 1:25 PM, RGB ES wrote: 2012/6/19 Jürgen Schmidt jogischm...@googlemail.com: Hi, I would like to propose that we prepare the first set of dev snapshots for AOO 3.4.1 based on the revision r1351633. We will start from now on to build and provide a dev snapshot every week for testing purposes. We can include Finnish and British English already because I have update both languages ones for testing. Languages for now: en-US ar cs de en-GB es fi fr gl hu it ja nl ru pt-BR zh-CN zh-TW Further languages can be included and the dead line is still end of June as proposed in my initial plan. I am trying to work on all requests for further languages, please send me a reminder if I have forget a language or if I have forgot to send you the po files. The builds will be made available under https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Unofficial+Developer+Snapshots Juergen Good! Which translation files will be included on this build? On last days I made lots of changes on pootle for ES locale and I would like to test the new translation. My plan is to update all official supported languages from Pootle at the beginning of July. You have made changes and that is is reflected in issue 119343. Please add a note in the issue of the translation is already finished and I will try include it in the next dev build. See also https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Feature+Planning Juergen Regards Ricardo
[Call for review]Bug 119537 - [From Symphony]ShapeExtrusionThe Extrusion direction of shape can't be saved correctly
Hi, all, I have a fix for this issue: https://issues.apache.org/ooo/show_bug.cgi?id=119537 Can anyone help review? See more details in issue comments. Thanks. Regards, Jianyuan
[CORRECTION] [RELEASE][3.4.1][DEV-BUILD]: propose first dev snapshot build for AOO 3.4.1 based on revision 1351649
my mistake, the revision should be 1351649 Sorry for the confusion Juergen On 6/19/12 1:15 PM, Jürgen Schmidt wrote: Hi, I would like to propose that we prepare the first set of dev snapshots for AOO 3.4.1 based on the revision r1351633. We will start from now on to build and provide a dev snapshot every week for testing purposes. We can include Finnish and British English already because I have update both languages ones for testing. Languages for now: en-US ar cs de en-GB es fi fr gl hu it ja nl ru pt-BR zh-CN zh-TW Further languages can be included and the dead line is still end of June as proposed in my initial plan. I am trying to work on all requests for further languages, please send me a reminder if I have forget a language or if I have forgot to send you the po files. The builds will be made available under https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Unofficial+Developer+Snapshots Juergen
Re: [RELEASE][3.4.1]: Include only one en-US dictionary extension
On 19.06.2012 13:07, Jürgen Schmidt wrote: [...] +1 for reducing the number of en dictionaries. Please propose a related issue for 3.4.1 that we can track it. Done. Issue number is 120033. -Andre
Re: OS/2 clipboard implementation not loaded
Hi Lin, it will call to create service com.sun.star.datatransfer.clipboard.SystemClipboard . In stoc\source\loader\dllcomponentloader.cxx(223) in function DllComponentLoader::activate(), it will load dll according to rLibName. debugging the code showed me that VCL was registering a X11ClipboardManager, so it was hiding the registration of SYSDTRANS. Now VCL component behaves like windows and clipboard started working magically :-)) thanks again for your help, -- Bye, Yuri Dario /* * OS/2 open source software * http://web.os2power.com/yuri * http://www.netlabs.org */
Re: [RELEASE][3.4.1][DEV-BUILD]: propose first dev snapshot build for AOO 3.4.1 based on revision 1351633
On Tue, Jun 19, 2012 at 01:15:31PM +0200, Jürgen Schmidt wrote: Hi, I would like to propose that we prepare the first set of dev snapshots for AOO 3.4.1 based on the revision r1351633. We will start from now on to build and provide a dev snapshot every week for testing purposes. We can include Finnish and British English already because I have update both languages ones for testing. Languages for now: en-US ar cs de en-GB es fi fr gl hu it ja nl ru pt-BR zh-CN zh-TW did you plan language packs + full install sets for every language, or only language packs + full install set in en-US? Further languages can be included and the dead line is still end of June as proposed in my initial plan. I am trying to work on all requests for further languages, please send me a reminder if I have forget a language or if I have forgot to send you the po files. please see http://s.apache.org/oL3 Regards -- Ariel Constenla-Haile La Plata, Argentina pgp9WweKQKuSK.pgp Description: PGP signature
Re: [RELEASE][3.4.1][DEV-BUILD]: propose first dev snapshot build for AOO 3.4.1 based on revision 1351633
Jürgen Schmidt wrote: We can include Finnish and British English already because I have update both languages ones for testing. Languages for now: en-US ar cs de en-GB es fi fr gl hu it ja nl ru pt-BR zh-CN zh-TW It would be good to add Slovenian too: Martin and Robert already submitted a full localization, cleared licensing issues and asked whether a build can be made available (it won't be a 3.4.0 build, but it will still be useful to them to test their translation). See http://s.apache.org/mZa for the full details. Regards, Andrea.
Re: [RELEASE][3.4.1][DEV-BUILD]: propose first dev snapshot build for AOO 3.4.1 based on revision 1351633
On 6/19/12 3:10 PM, Ariel Constenla-Haile wrote: On Tue, Jun 19, 2012 at 01:15:31PM +0200, Jürgen Schmidt wrote: Hi, I would like to propose that we prepare the first set of dev snapshots for AOO 3.4.1 based on the revision r1351633. We will start from now on to build and provide a dev snapshot every week for testing purposes. We can include Finnish and British English already because I have update both languages ones for testing. Languages for now: en-US ar cs de en-GB es fi fr gl hu it ja nl ru pt-BR zh-CN zh-TW did you plan language packs + full install sets for every language, or only language packs + full install set in en-US? I would build full install sets for 3.4.1 and later for the dev builds on trunk (3.5) we can start with en-US + lang packs. I hope we can address this packaging stuff in a good way in the future... Further languages can be included and the dead line is still end of June as proposed in my initial plan. I am trying to work on all requests for further languages, please send me a reminder if I have forget a language or if I have forgot to send you the po files. please see http://s.apache.org/oL3 I have seen this, thanks for the reminder. I am currently want to finish my signing evaluation which of course looks good and than I will come back to the Pootle stuff. Juergen
Re: Propose for 3.4.1: Can't remove password from file (119366)
On 6/18/12 1:16 AM, Rob Weir wrote: https://issues.apache.org/ooo/show_bug.cgi?id=119366 This is a regression introduced in OOo 3.4 beta but not detected in AOO 3.4 tested. Once a password is set it cannot be removed. Two users have reported it. -Rob can we agree on subject line like [RELEASE][3.4.1]: that makes it easier to track all release relevant things +1 for this issue Juergen
Re: [RELEASE][3.4.1][DEV-BUILD]: propose first dev snapshot build for AOO 3.4.1 based on revision 1351633
On 6/19/12 3:19 PM, Andrea Pescetti wrote: Jürgen Schmidt wrote: We can include Finnish and British English already because I have update both languages ones for testing. Languages for now: en-US ar cs de en-GB es fi fr gl hu it ja nl ru pt-BR zh-CN zh-TW It would be good to add Slovenian too: Martin and Robert already submitted a full localization, cleared licensing issues and asked whether a build can be made available (it won't be a 3.4.0 build, but it will still be useful to them to test their translation). See http://s.apache.org/mZa for the full details. The proposed way is to create an issue like https://issues.apache.org/ooo/show_bug.cgi?id=119343 with subject: Language translation for 3.4.1 and the po files attached. The process is still not optimal here and if any volunteer would like to help please let me know. The files have to be included and that requires some work ;-) Please be patient... But again volunteers can step up and can join the effort to improve the process Juergen
Re: [RELEASE][3.4.1][DEV-BUILD]: propose first dev snapshot build for AOO 3.4.1 based on revision 1351633
On 6/19/12 4:21 PM, Andrea Pescetti wrote: Jürgen Schmidt wrote: On 6/19/12 3:19 PM, Andrea Pescetti wrote: It would be good to add Slovenian too: Martin and Robert already submitted a full localization ... The proposed way is to create an issue See https://issues.apache.org/ooo/show_bug.cgi?id=120036 with subject: Language translation for 3.4.1 and the po files attached. They provided the SDF translation directly. This should also be easier to integrate in the sources. New translations are release blockers, so I expect this to be considered a 3.4.1 blocker with no need for discussion. we should at least discuss if we want to release the language ;-) No default mechanism ... Juergen
Re: Slovak language
On 6/18/12 7:57 PM, Risto Jääskeläinen wrote: Hello I am just a Finnish localizator and I have only contributor rights to Pootle. So what I can do to help? 1) Here is link about rights to Pootle: https://cwiki.apache.org/confluence/display/INFRA/translate+pootle+service+auth+levels If only I have that right to Can download archives of a translation project then it would be possible to send you total slovak package from Pootle It would be possible to translate as offline and then send the package via the issue tracker (if 1MB). Now it is possible to you made suggestions into Pootle for Slovak translations. But if there is nobody else who understand the language ... So you need some more rights to Apache Pootle or some more powerfull friend to send to you the package. I will prepare the po files for you and will send you the files tomorrow. The esiest way to get started is to work offline for now. I will send you further info with the po files (and will create general docu). Welcome on board and thanks for joining the project Juergen I hope you find somebody. Regards, Risto Michal Hriň [michalh...@aol.com] kirjoitti: Hi everyone, I am Michal Hriň, unemployed student, so I got some free time for participation. There is no Slovak language pack for AOO. First time I would like to translate the files on Pootle server, but there is no option for registration. Can you help me create a Slovak Language pack ? Regards, Michal Hriň
Re: [Proposal] Guidelines for list conduct policy
On 18 June 2012 13:30, RGB ES rgb.m...@gmail.com wrote: 2012/6/18 Rob Weir robw...@apache.org: 1. What Happens in Vegas, Stays in Vegas: Anything you read in the private list is by default a private PPMC affair and not to be spoken of, or copied to other people who are not in the PPMC. If you think about it, most topic threads probably should be in the public lists, except choosing committers and PPMC members, and a very few others. In fact, all email lists or email conversations have this aspect of privacy. Even if there are 23000 subscribers on the list, it is assumed that privacy will be maintained and a list member's name and location will not be published in a newspaper or some other public venue where personal privacy is not expected. I like it. You write well, with style. But I do wonder if What happens in Vegas... is well understood outside of the USA? Of course, everyone should watch The Hangover ;-) The phrase is clear from context... but not by itself. At least not for me. I think the phrase may give the wrong impression. I assumed it was akin to don't broadcast what happens on a stag night but having done an internet search I see it's perhaps not quite the same. Nevertheless, I suggest a change to something less culturally biased and with less likelihood of misinterpretation.
Re: [RELEASE][3.4.1]: Include only one en-US dictionary extension
On 19/06/2012 15:01, Dave Fisher wrote: But none of you are native English speakers. English varies from country to country around the world. Why not disable or rename the second version when the name collides? Regards, Dave Sent from my iPhone On Jun 19, 2012, at 7:07 AM, Jürgen Schmidt jogischm...@googlemail.com wrote: On 6/19/12 9:17 AM, Andre Fischer wrote: On 19.06.2012 05:07, Ariel Constenla-Haile wrote: Hi there, there have been some reports of users complaining that the Thesaurus does not work. The root of the issue is in the dictionary extensions we are shipping: two of them collide due to lack of uniqueness in the configuration node name, namely dict-en.oxt (the generic EN dictionary) and dict-en-nz-2008-12-03.oxt. The conflict happens on the Thesaurus node: * dict-en.oxt: node oor:name=ThesDic_en-US oor:op=fuse prop oor:name=Locations oor:type=oor:string-list value%origin%/th_en_US_v2.dat/value /prop prop oor:name=Format oor:type=xs:string valueDICT_THES/value /prop prop oor:name=Locales oor:type=oor:string-list valueen-GB en-US en-ZA en-AU en-CA/value /prop /node * dict-en-nz-2008-12-03.oxt: node oor:name=ThesDic_en-US oor:op=fuse prop oor:name=Locations oor:type=oor:string-list value%origin%/th_en_US_v2.dat/value /prop prop oor:name=Format oor:type=xs:string valueDICT_THES/value /prop prop oor:name=Locales oor:type=oor:string-list valueen-NZ/value /prop /node As you see, they have the same name, ThesDic_en-US, despite the fact that the official documentation states clearly that dictionary extension developers should use a unique node name, see http://wiki.services.openoffice.org/wiki/Extension_Dictionaries#Dictionary_entries_.28must_be_provided.29 specially About node names for the dictionaries. The thesaurus file in dict-en-au-2008-12-15 did rename the thesaurus file to th_en_AU_v2.dat. That avoids the conflict but still wastes 18MB of disk space. I didn't research what the fuse operation is *supposed* to do there (it's applied to the node, not to the properties), but the documentation is clear in stating that the node name must be unique. And the result is that the properties are not fused but replaced, having as effect that the en-NZ dictionary installed disables the thesaurus for en-US. As this bug has its root in the dictionary extensions, the only thing we can do to fix it is just provide only one extension, in this case dict-en.oxt. Dropping the other english dictionaries is a good idea for other reasons, too. Issue 119272 (https://issues.apache.org/ooo/show_bug.cgi?id=119272) describes the problem of all dictionaries using more than 160MB, most of this are the large thesaurus files. Including only one english dictionary would reduce this number considerably. Besides, it contains support for most variants of English anyway. +1 for reducing the number of en dictionaries. Please propose a related issue for 3.4.1 that we can track it. Please no commits on AOO34 without a 3.4.1 issue! Juergen -Andre Note that I only discovered this bug in the English dictionary extensions, I didn't check other languages, but we should do so in the cases where we're providing more than one dictionary extension. Regards Surely this should be listed as a bug against dict-en-nz-2008-12-03.oxt ? Please don't merrily discard the English language variant dictionaries - they are really really important. Stuart -- Stuart Swales
Re: Tutorial: How to Use the Apache CMS Web Interface
On Tue, Jun 19, 2012 at 12:18 PM, Ross Gardler rgard...@opendirective.com wrote: This is great Rob. I've linked to it from the ComDev site. At the end you ask for suggestions and requests... The only part of this that is specific to OOo is the initial technique for finding the bookmarklet. It would be great if you could provide an Apache short URL and put that in the video as an overlay (i.e. alternatively type s.apache.org/cms into your browser -note that is a real shorturl I just created) Done. Can we have one for non-committers that shows them how to edit and submit a patch? Yes, that would be a good part 2. (Or part 0) -Rob On 15 June 2012 14:09, Rob Weir robw...@apache.org wrote: My first attempt making a video with Camtasia. Hopefully this will be useful to someone starting to use the CMS for the first time: http://www.youtube.com/watch?v=xcDZN3Lu6HA Regards, -Rob -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
Re: Approaching 5M downloads
On 2012-06-19, at 13:37 , Rob Weir wrote: We're at 4,922,774. So we should hit 5M late tonight or early tomorrow morning (UTC). I'll work on a blog post highlighting that milestone and give a general update on what we are working on. After that I plan to stop reporting on each 1M increment. They come too quickly. Maybe an update every 5M in the future? Perhaps issue a graphic, too: the curve seems to be steepening. Louis -Rob
Re: Approaching 5M downloads
On Tue, Jun 19, 2012 at 7:37 PM, Rob Weir robw...@apache.org wrote: We're at 4,922,774. So we should hit 5M late tonight or early tomorrow morning (UTC). I'll work on a blog post highlighting that milestone and give a general update on what we are working on. After that I plan to stop reporting on each 1M increment. They come too quickly. Loved this. :) Maybe an update every 5M in the future? It sounds reasonable to me. Roberto -Rob -- 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: [RELEASE][3.4.1][DEV-BUILD]: propose first dev snapshot build for AOO 3.4.1 based on revision 1351633
Jürgen Schmidt wrote: On 6/19/12 4:21 PM, Andrea Pescetti wrote: See https://issues.apache.org/ooo/show_bug.cgi?id=120036 New translations are release blockers, so I expect this to be considered a 3.4.1 blocker with no need for discussion. we should at least discuss if we want to release the language ;-) No default mechanism ... Well, everything happened on this list, and it has happened since June 1st, so people had plenty of time to comment. It was OK for Kay, me and you. You wrote that you would take care of including Slovenian in 3.4.1 and nobody opposed. I'd say lazy consensus has already been reached, but if anyone has anything against including Slovenian in 3.4.1 he can just write here or in the aforementioned issue. I can't read Slovenian, but since the guys have translated OpenOffice.org for years I'm confident about the translation quality. Regards, Andrea.
Re: official logos ???
On Mon, Jun 18, 2012 at 6:18 PM, Hagar Delest hagar.del...@laposte.net wrote: Le lun. 18 juin 2012 00:54:08 CEST, Rob Weir robw...@apache.org a écrit : On Sun, Jun 17, 2012 at 6:38 PM, Hagar Delest hagar.del...@laposte.net wrote: I don't see any clear direction for the logos. Can you be more specific? What do you think needs clarification? Current branding is a mix of the refresh set with the orb (Start center, splash screen, taskbar, about, ...) and former icons (MIME, applications). It's rather strange because there is a gap between the new icons and the old ones (the old set is quite old fashioned IMHO). Yes. The rebranding was only partially applied in AOO 3.4. There is more work to be done here. We had a logo contest and vote for AOO 3.4.0. I think AOO 3.4.1 will use the same logo. I don't remember any vote at all. I've found that old thread dated end of last year: old colored vs new monochrome icons. Rather long so will have a look at it tomorrow. But if there is a message that concludes it, it would be great! This was a more recent set of threads, in early April. I've checked the following page and its child pages: https://cwiki.apache.org/confluence/display/OOOUSERS/Branding+Planning Only the product logo is clearly mentioned as voted. NB: will review the old colored vs new monochrome icons topic and either revive it or create a new topic. Target being to make progress on the MIME and application icons (at least for AOO 4). For the record: Old icons: http://www.openoffice.org/ui/VisualDesign/OOo30MimeType.html Refresh icons: http://www.openoffice.org/ui/VisualDesign/OOo3_refresh.html LibO icons (worth a look IMHO): http://wiki.documentfoundation.org/Marketing/Branding/Mimetype_Icons/Proposals This was not about the toolbar icons, but about website logo. Maybe we are talking about two different things? -Rob Hagar
Re: [PROPOSAL] Apache OpenOffice Conference 2012
On 2012-06-18, at 09:43 , Dave Fisher wrote: On Jun 18, 2012, at 1:44 AM, Roberto Galoppini wrote: On Mon, Jun 18, 2012 at 2:52 AM, Peter Junge peter.ju...@gmx.org wrote: Looks like this thread didn't continue. Maybe because other topics that started a bit later were interfering. Let's see if we can revamp it, here and now. It's very unlike that I will be able to attend in person, but you can count me in if you need reviewers for the call for papers. As soon as we'll start to promote the event we might customize the Apache OpenOffice displayed in the SourceForge top carousel (see http://sourceforge.net/directory) to inform our audience about the event. How do you like the idea? I like the idea very much. Likewise. Louis Regards, Dave Roberto Peter On 6/9/2012 3:11 AM, Donald Harbison wrote: We have the opportunity to frame up and build a 'conference within a conference' within the ApacheCON EU 2012 venue, November 5 - 9th in Sinsheim, Germany. I've pulled an outline together on the wiki [1]. This is a 'call-to-action'. If you want to see this idea become a reality, now is the time to volunteer. Timing is urgent here. In the northern hemisphere, many of us will go off on vacations in July and August. We need to earn our space from ConComm and the other ApacheCon volunteers if this idea has any hope of success. Note that if you volunteer for this effort, you will also need to help out with the broader conference as well. Share and share alike! I have asked that we sharpen our proposal and submit it to ConComm by Friday, June 22nd... in two weeks time. Yes, that's compressed, but I believe we have sufficiently experienced PPMC members who know what it takes to make something like this happen. I've started a proposed committee list on the wiki, but that's all it is a 'start'. This is a great opportunity to re-boot our OpenOffice community in its country of origin. I'm personally very excited about this, and hope you are too. Please engage and make this happen. [1] *http://s.apache.org/4cp* -- 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: Approaching 5M downloads
Am 06/19/2012 07:37 PM, schrieb Rob Weir: We're at 4,922,774. So we should hit 5M late tonight or early tomorrow morning (UTC). I'll work on a blog post highlighting that milestone and give a general update on what we are working on. After that I plan to stop reporting on each 1M increment. They come too quickly. Yeah, it's seems indeed very quick. Maybe an update every 5M in the future? What about 10M as next step? Marcus
Translation testing
On Tue, Jun 19, 2012 at 3:31 PM, Andrea Pescetti pesce...@apache.org wrote: Jürgen Schmidt wrote: On 6/19/12 4:21 PM, Andrea Pescetti wrote: See https://issues.apache.org/ooo/show_bug.cgi?id=120036 New translations are release blockers, so I expect this to be considered a 3.4.1 blocker with no need for discussion. we should at least discuss if we want to release the language ;-) No default mechanism ... Well, everything happened on this list, and it has happened since June 1st, so people had plenty of time to comment. It was OK for Kay, me and you. You wrote that you would take care of including Slovenian in 3.4.1 and nobody opposed. I'd say lazy consensus has already been reached, but if anyone has anything against including Slovenian in 3.4.1 he can just write here or in the aforementioned issue. I can't read Slovenian, but since the guys have translated OpenOffice.org for years I'm confident about the translation quality. Moving this to its own thread. If we want to have a reputation for high quality I think we need to find a way to get beyond solo translations, by which I mean translations done by own person, with no independent review. We would never accept a code contribution in a language we could not read or test, right? We wouldn't ship an OS port if we didn't have more than one user able to test it, would we? And look at existing translations. Even though we are not really changing the UI in 3.4.1 we're getting a stream of corrections to the AOO 3.4.0 translations. This is not surprising. Errare humanum est. Even repetitive data transcription tasks can have a 5% error rate. That's why where accuracy is important we have consistency checks, for example checksum digits in credit card and ISBN numbers. That's why we do QA with code. That is why we have spell checkers. It is almost guaranteed that a solo translation will have a higher error rate. What can we do about this? Maybe we can promote the availability of a new translation, with help from the translator, among our user base. So notices on Twitter, blogs, and native-language tech sites. Invite users to download snapshot builds with the goal of verifying the localization. If a translation is worth doing we should be able to find a community (even a small one) of users to help with this work. Any other ideas? Regards, -Rob Regards, Andrea.
Re: svn commit: r1351633 - in /incubator/ooo/trunk/main: instsetoo_native/util/openoffice.lst solenv/inc/version.lst sysui/desktop/productversion.mk
Am 06/19/2012 12:00 PM, schrieb j...@apache.org:
Author: jsc
Date: Tue Jun 19 10:00:15 2012
New Revision: 1351633
URL: http://svn.apache.org/viewvc?rev=1351633view=rev
Log:
119977: update version number to 3.5
Modified:
incubator/ooo/trunk/main/instsetoo_native/util/openoffice.lst
incubator/ooo/trunk/main/solenv/inc/version.lst
incubator/ooo/trunk/main/sysui/desktop/productversion.mk
Modified: incubator/ooo/trunk/main/instsetoo_native/util/openoffice.lst
URL:
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/instsetoo_native/util/openoffice.lst?rev=1351633r1=1351632r2=1351633view=diff
==
--- incubator/ooo/trunk/main/instsetoo_native/util/openoffice.lst (original)
+++ incubator/ooo/trunk/main/instsetoo_native/util/openoffice.lst Tue Jun 19
10:00:15 2012
@@ -4,15 +4,15 @@ Globals
{
variables
{
- SERVICETAG_PRODUCTNAME OpenOffice.org 3.4
- SERVICETAG_PRODUCTVERSION 3.4
- SERVICETAG_PARENTNAME OpenOffice.org 3.4
+ SERVICETAG_PRODUCTNAME OpenOffice.org 3.5
+ SERVICETAG_PRODUCTVERSION 3.5
+ SERVICETAG_PARENTNAME OpenOffice.org 3.5
SERVICETAG_SOURCE {buildsource}{minor}(Build:{buildid})
SERVICETAG_URN
urn:uuid:500061aa-5666-11e0-8e00-080020a9ed93
BTW:
IMHO another nice example to get rid of old and no longer needed code:
The Service Tag [1] implementation from what has Sun included.
It's very simple:
We don't want any registrations -- so we don't need Service Tags anymore.
[1]
http://www.oracle.com/technetwork/articles/javase/productregistration-142210.html
My 2 ct.
Marcus
Re: [RELEASE][3.4.1][DEV-BUILD]: propose first dev snapshot build for AOO 3.4.1 based on revision 1351633
Am 06/19/2012 01:15 PM, schrieb Jürgen Schmidt: Hi, I would like to propose that we prepare the first set of dev snapshots for AOO 3.4.1 based on the revision r1351633. We will start from now on to build and provide a dev snapshot every week for testing purposes. We can include Finnish and British English already because I have update both languages ones for testing. Languages for now: en-US ar cs de en-GB es fi fr gl hu it ja nl ru pt-BR zh-CN zh-TW Further languages can be included and the dead line is still end of June as proposed in my initial plan. I am trying to work on all requests for further languages, please send me a reminder if I have forget a language or if I have forgot to send you the po files. The builds will be made available under https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Unofficial+Developer+Snapshots Great to see progress with new Dev Builds. I would suggest to reuse the old page (rename it first to get rid of the version number). Then you don't need always to build up a new page and the download webpage doesn't need to be updated everytime with a new link which difference is just the version number. So, a webpage URL name like this would be better and chances to live longer are much higher. ;-) https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+Unofficial+Developer+Snapshots Marcus
Re: [Proposal] Guidelines for list conduct policy
On 19/06/12 21:26, Ross Gardler wrote: Top posting as I'm not commenting on the text itself. I'd like to request that this document clarifies the purpose of the private list - we don't want to give the impression that the project conducts essential business on the private list. (My new text amendments are at the bottom.) That would make sense - but these are guidelines for all AOO mailing lists, aren't they? This isn't specific to the ooo-private? Dave. Sent from my mobile device, please forgive errors and brevity. On Jun 16, 2012 4:26 PM, Wolf Haltonwolf.hal...@gmail.com wrote: This is a draft with the additions from the group, for a lazy consensus. I am envisioning that the final draft can be added to the sign-in progress for the various mailing-lists and also as a link to the project mailing-list page. I have not included any pieces about what happens to an individual who does not abide by the general group agreements, as that has not been discussed here yet. -- List Conduct Policy 1. What Happens in Vegas, Stays in Vegas: Anything you read in the private list is by default a private PPMC affair and not to be spoken of, or copied to other people who are not in the PPMC. If you think about it, most topic threads probably should be in the public lists, except choosing committers and PPMC members, and a very few others. In fact, all email lists or email conversations have this aspect of privacy. Even if there are 23000 subscribers on the list, it is assumed that privacy will be maintained and a list member's name and location will not be published in a newspaper or some other public venue where personal privacy is not expected. 2. Be Nice: Not only are there lots of people on this list whose first language is not English, there are busy hurried readers. If other list members are telling you they do not understand what you wrote, or take your innocent phasing in a poor light, take it as a signal that your writing style is too idiomatic or too technical (unlikely but possible) for others to follow easily. This does not necessarily mean you are mean, wrong and bad, so just be nice and reword the passage. Assume people are not in attack mode. We are all on the same team here. 3. Don't Respond When You are Angry: Presuming people are not in attack mode means, if you think they are, just now, then probably you are just misunderstanding their point. Ad hominem attacks, e.g., You are too dumb to get this, are a sign that you yourself may not have a good-enough handle on the issue to explain your point clearly. 4. Relax: Always remember, that unless there is a *darn* good reason, nothing gets decided at the ASF in less than 72 elapsed hours, so your reply can wait until morning. You might even get lucky, and when you check back somebody else will have posted either what you wanted to say, or something close enough that you can work with it. Remember that the members of a community mailing list will get to the list when they can. Most of us do this in our spare time, and in different time zones. Perhaps the rule of thumb could be to respond no more than once per hour, or once per day, to any given thread. The highest frequency of responses does not necessarily “Win” in a community of equals. The most concise and useful post tends to win, if furthering the dialog and advancing the community's goals is what we are after.. 5. Get to the Point: Write as tersely as possible, and edit down as much possible, so other people who are just as busy as you may quickly get your point without ending up defensive. 6. Consider trimming the post to which you are responding: People who read emails on small screens are not the only ones who are frustrated by picking important new information out of tons of stuff they have already read. To trim a post, one simply remove any parts of the post to which one is replying that are not important to understand ones reply. If the response to one of these posts is, “What? I do not understand,” then it may be that too much of the context may have been removed. 7. There are Going to be Exceptions to the Rule: All of these guidelines are subject to sanity-testing. A person posting child porn on this list will be reported to the appropriate authorities and will not be able to complain that their list privacy has been violated. Ramping up to a release, there are a lot of postings at high frequency. Sometimes it takes a long post to say what needs to be said. More Useful Stuff: Apache Tips for Email Contributors – http://www.apache.org/dev/contrib-email-tips.html http://www.apache.org/dev/contrib-email-tips.html Apache OpenOffice Mailing Lists – http://incubator.apache.org/openofficeorg/mailing-lists.html
Re: [RELEASE][3.4.1]: Include only one en-US dictionary extension
Le mar. 19 juin 2012 12:25:28 CEST, RGB ES rgb.m...@gmail.com a écrit : 2012/6/19 Ariel Constenla-Haile arie...@apache.org: As this bug has its root in the dictionary extensions, the only thing we can do to fix it is just provide only one extension, in this case dict-en.oxt. +1 for just one dictionary. IMO, the whole idea for an extension system is to provide a *baseline* and let the users install what they need. When several dictionaries are available for a single language, to provide the most common is the best move. Regards Ricardo +1. Hagar
Re: [Proposal] Guidelines for list conduct policy
On Tue, 2012-06-19 at 22:32 +0100, David McKay wrote: On 19/06/12 21:26, Ross Gardler wrote: Top posting as I'm not commenting on the text itself. I'd like to request that this document clarifies the purpose of the private list - we don't want to give the impression that the project conducts essential business on the private list. (My new text amendments are at the bottom.) That would make sense - but these are guidelines for all AOO mailing lists, aren't they? This isn't specific to the ooo-private? Dave. Sent from my mobile device, please forgive errors and brevity. On Jun 16, 2012 4:26 PM, Wolf Haltonwolf.hal...@gmail.com wrote: This is a draft with the additions from the group, for a lazy consensus. I am envisioning that the final draft can be added to the sign-in progress for the various mailing-lists and also as a link to the project mailing-list page. I have not included any pieces about what happens to an individual who does not abide by the general group agreements, as that has not been discussed here yet. -- List Conduct Policy 1. What Happens in Vegas, Stays in Vegas: Anything you read in the private list is by default a private PPMC affair and not to be spoken of, or copied to other people who are not in the PPMC. If you think about it, most topic threads probably should be in the public lists, except choosing committers and PPMC members, and a very few others. In fact, all email lists or email conversations have this aspect of privacy. Even if there are 23000 subscribers on the list, it is assumed that privacy will be maintained and a list member's name and location will not be published in a newspaper or some other public venue where personal privacy is not expected. 2. Be Nice: Not only are there lots of people on this list whose first language is not English, there are busy hurried readers. If other list members are telling you they do not understand what you wrote, or take your innocent phasing in a poor light, take it as a signal that your writing style is too idiomatic or too technical (unlikely but possible) for others to follow easily. This does not necessarily mean you are mean, wrong and bad, so just be nice and reword the passage. Assume people are not in attack mode. We are all on the same team here. 3. Don't Respond When You are Angry: Presuming people are not in attack mode means, if you think they are, just now, then probably you are just misunderstanding their point. Ad hominem attacks, e.g., You are too dumb to get this, are a sign that you yourself may not have a good-enough handle on the issue to explain your point clearly. 4. Relax: Always remember, that unless there is a *darn* good reason, nothing gets decided at the ASF in less than 72 elapsed hours, so your reply can wait until morning. You might even get lucky, and when you check back somebody else will have posted either what you wanted to say, or something close enough that you can work with it. Remember that the members of a community mailing list will get to the list when they can. Most of us do this in our spare time, and in different time zones. Perhaps the rule of thumb could be to respond no more than once per hour, or once per day, to any given thread. The highest frequency of responses does not necessarily “Win” in a community of equals. The most concise and useful post tends to win, if furthering the dialog and advancing the community's goals is what we are after.. 5. Get to the Point: Write as tersely as possible, and edit down as much possible, so other people who are just as busy as you may quickly get your point without ending up defensive. 6. Consider trimming the post to which you are responding: People who read emails on small screens are not the only ones who are frustrated by picking important new information out of tons of stuff they have already read. To trim a post, one simply remove any parts of the post to which one is replying that are not important to understand ones reply. If the response to one of these posts is, “What? I do not understand,” then it may be that too much of the context may have been removed. 7. There are Going to be Exceptions to the Rule: All of these guidelines are subject to sanity-testing. A person posting child porn on this list will be reported to the appropriate authorities and will not be able to complain that their list privacy has been violated. Ramping up to a release, there are a lot of postings at high frequency. Sometimes it takes a long post to say what needs to be said. More Useful Stuff:
Re: [Proposal] Guidelines for list conduct policy
2012/6/20 drew jensen drewjensen.in...@gmail.com: List Conduct Policy 1. What Happens on the list, stays on the list: Anything you read in the private list is by default a private PPMC affair and not to be spoken of, or copied to, other people who are not in the PPMC. If you think about it, most topic threads probably should be in the public lists, except choosing committers and PPMC members, and a very few other topics. In fact, all email lists or email conversations have this aspect of privacy. Even if there are 23000 subscribers on the list, it is assumed that privacy will be maintained and a list member's name and location will not be disclosed in some public venue where personal privacy is not expected, such as published in a newspaper or some other. hi, I would disagree with that last statement completely - a public list is just that, public, and there should be absolutely no expectation of privacy whatsoever. To pretend otherwise is simply to lie to those who would use the list. //drew Point one refers to the private lists, I think. Maybe add a point zero with an introduction to the mailing lists, as Ross asked? Not a detailed introduction, just to say most lists are public but one is private. Then the code of conduct can be separated on a general part that apply to all lists and a second part with additional rules (for instance, the privacy one) for the private list. Ricardo
Re: [RELEASE][3.4.1]: Include only one en-US dictionary extension
Sent from my iPhone On Jun 19, 2012, at 9:19 AM, Ariel Constenla-Haile arie...@apache.org wrote: On Tue, Jun 19, 2012 at 10:01:10AM -0400, Dave Fisher wrote: But none of you are native English speakers. English varies from country to country around the world. Why not disable or rename the second version when the name collides? we cannot edit the extensions, they are downloaded and packaged as is. On the other hand, the dict-en.oxt is a general dictionary extension, it supports the following locales: en-GB en-US en-ZA en-AU en-CA Would it be possible to reject extensions where the name collides inside of AOO? Perhaps a description of why the extension manager chooses the bad NZ over the preferred and correctly named versions? Is the last or first with the name chosen? Would a known bad actor patch work? The proposed solution effects many more users than are experiencing the problem. After all we are adding en-GB in this version. Regards, Dave Regards -- Ariel Constenla-Haile La Plata, Argentina
Re: [Proposal] Guidelines for list conduct policy
On Wed, 2012-06-20 at 00:14 +0200, RGB ES wrote: 2012/6/20 drew jensen drewjensen.in...@gmail.com: List Conduct Policy 1. What Happens on the list, stays on the list: Anything you read in the private list is by default a private PPMC affair and not to be spoken of, or copied to, other people who are not in the PPMC. If you think about it, most topic threads probably should be in the public lists, except choosing committers and PPMC members, and a very few other topics. In fact, all email lists or email conversations have this aspect of privacy. Even if there are 23000 subscribers on the list, it is assumed that privacy will be maintained and a list member's name and location will not be disclosed in some public venue where personal privacy is not expected, such as published in a newspaper or some other. hi, I would disagree with that last statement completely - a public list is just that, public, and there should be absolutely no expectation of privacy whatsoever. To pretend otherwise is simply to lie to those who would use the list. //drew Point one refers to the private lists, I think. Maybe add a point zero with an introduction to the mailing lists, as Ross asked? Not a detailed introduction, just to say most lists are public but one is private. Then the code of conduct can be separated on a general part that apply to all lists and a second part with additional rules (for instance, the privacy one) for the private list. Ricardo OK if that is really just about private lists, but the last sentence read to me as if it was broader. Anyway - to be honest I find the whole subject rather silly. Does anyone really need to be told that what happens on a private list is by definition to be held in confidence? //drew
Re: Java
On 06/19/2012 12:29 PM, Maya Cain wrote: I had an older copy of OpenOffice which ran very well but then I found there was a newer version and so I updated and now my database will not work. I get a message saying that the Java environment has changed. The text function and the spreadsheets both appear to be working. Can you tell me, please, what I need to do to fix this as I have a very large database which, at the moment, I cannot edit. Thank you for any help. Maya Cain Not entirely sure, but try this: Use Tools Options OpenOffice.org Java The top check box should be set to use Java. It may take a bit, but a list of available Java implementations should be shown. I may be mistaken, but, I think that OOo will work with a java version 1.6.x but not 1.7.x, so, select a version that begins with 1.6. Much of OOo does not require Java. The database portion does I believe. -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php
Re: [Proposal] Guidelines for list conduct policy
On Tue, Jun 19, 2012 at 3:33 PM, drew d...@baseanswers.com wrote: On Wed, 2012-06-20 at 00:14 +0200, RGB ES wrote: 2012/6/20 drew jensen drewjensen.in...@gmail.com: List Conduct Policy 1. What Happens on the list, stays on the list: Anything you read in the private list is by default a private PPMC affair and not to be spoken of, or copied to, other people who are not in the PPMC. If you think about it, most topic threads probably should be in the public lists, except choosing committers and PPMC members, and a very few other topics. In fact, all email lists or email conversations have this aspect of privacy. Even if there are 23000 subscribers on the list, it is assumed that privacy will be maintained and a list member's name and location will not be disclosed in some public venue where personal privacy is not expected, such as published in a newspaper or some other. hi, I would disagree with that last statement completely - a public list is just that, public, and there should be absolutely no expectation of privacy whatsoever. To pretend otherwise is simply to lie to those who would use the list. //drew Point one refers to the private lists, I think. Maybe add a point zero with an introduction to the mailing lists, as Ross asked? Not a detailed introduction, just to say most lists are public but one is private. Then the code of conduct can be separated on a general part that apply to all lists and a second part with additional rules (for instance, the privacy one) for the private list. Ricardo OK if that is really just about private lists, but the last sentence read to me as if it was broader. Anyway - to be honest I find the whole subject rather silly. Does anyone really need to be told that what happens on a private list is by definition to be held in confidence? //drew Well, Drew, I think this is why this whole discussion started. Most of us would think the answer to your question is no, but, well, apparently there was some looser interpretation that some felt needed clarification. Anyway, Wolf, this is really good. I think this would be better posted as just a link on the project site, http://incubator.apache.org/openofficeorg/, under the Mailing Lists link, and give more clarification on item #1 that this most importantly applies to private mailing lists. Drew's right that we don't want to mislead people to think anything else is private. I think maybe it's a bit lengthy to add to a welcome message to list subscribers. -- MzK Known commonly as the jackass, this long-eared little creature is respected throughout the southwest—roundly cursed yet respected—and here he is usually referred to by his Spanish name, burro. Because of his extraordinary bray, he is sometimes ironically called the Arizona Nightingale. -- Arizona, the Grand Canyon State: A State Guide, By Federal Writers' Project
Re: [Proposal] Guidelines for list conduct policy
On Tue, Jun 19, 2012 at 7:42 PM, drew d...@baseanswers.com wrote: On Tue, 2012-06-19 at 16:21 -0700, Kay Schenk wrote: On Tue, Jun 19, 2012 at 3:33 PM, drew d...@baseanswers.com wrote: On Wed, 2012-06-20 at 00:14 +0200, RGB ES wrote: 2012/6/20 drew jensen drewjensen.in...@gmail.com: List Conduct Policy 1. What Happens on the list, stays on the list: Anything you read in the private list is by default a private PPMC affair and not to be spoken of, or copied to, other people who are not in the PPMC. If you think about it, most topic threads probably should be in the public lists, except choosing committers and PPMC members, and a very few other topics. In fact, all email lists or email conversations have this aspect of privacy. Even if there are 23000 subscribers on the list, it is assumed that privacy will be maintained and a list member's name and location will not be disclosed in some public venue where personal privacy is not expected, such as published in a newspaper or some other. hi, I would disagree with that last statement completely - a public list is just that, public, and there should be absolutely no expectation of privacy whatsoever. To pretend otherwise is simply to lie to those who would use the list. //drew Point one refers to the private lists, I think. Maybe add a point zero with an introduction to the mailing lists, as Ross asked? Not a detailed introduction, just to say most lists are public but one is private. Then the code of conduct can be separated on a general part that apply to all lists and a second part with additional rules (for instance, the privacy one) for the private list. Ricardo OK if that is really just about private lists, but the last sentence read to me as if it was broader. Anyway - to be honest I find the whole subject rather silly. Does anyone really need to be told that what happens on a private list is by definition to be held in confidence? //drew Well, Drew, I think this is why this whole discussion started. Most of us would think the answer to your question is no, but, well, apparently there was some looser interpretation that some felt needed clarification. Not at all - someone violated that trust, everyone knew it was wrong, there didn't need to be rules written for folks to know that. But that is just my opinion of course. Anyway, Wolf, this is really good. I think this would be better posted as just a link on the project site, http://incubator.apache.org/openofficeorg/, under the Mailing Lists link, and give more clarification on item #1 that this most importantly applies to private mailing lists. Drew's right that we don't want to mislead people to think anything else is private. I think maybe it's a bit lengthy to add to a welcome message to list subscribers. The #1 entry is the most reactionary meaning it is in reaction to an event or events which we as a group never want to see again, and such is probably a dangerous step toward totalitarianism. I, and others have defanged it somewhat. I know it needs to be clarified to limit its scope to only the private lists or specifically the PPMC list and Security list. Maybe that paragraph should be #7 and something else should be at the top, as there are only a small percentage who are members of the PPMC/Security and a lot more who are part of dev@ or Users@ or marketing@ etc.. -Wolf -- This Apt Has Super Cow Powers - http://sourcefreedom.com Open-Source Software in Libraries - http://FOSS4Lib.org Advancing Libraries Together - http://LYRASIS.org Apache Open Office Developer wolfhal...@apache.org
Re: Tutorial: How to Use the Apache CMS Web Interface
On 06/15/2012 09:09 AM, Rob Weir wrote: My first attempt making a video with Camtasia. Hopefully this will be useful to someone starting to use the CMS for the first time: http://www.youtube.com/watch?v=xcDZN3Lu6HA Regards, -Rob Nice job. Good video. Thanks, Carl
Re: Translation testing
On Tue, Jun 19, 2012 at 5:30 PM, Alexandro Colorado j...@oooes.org wrote: On Tue, Jun 19, 2012 at 4:09 PM, RGB ES rgb.m...@gmail.com wrote: 2012/6/19 Rob Weir robw...@apache.org: If we want to have a reputation for high quality I think we need to find a way to get beyond solo translations, by which I mean translations done by own person, with no independent review. We would never accept a code contribution in a language we could not read or test, right? We wouldn't ship an OS port if we didn't have more than one user able to test it, would we? And look at existing translations. Even though we are not really changing the UI in 3.4.1 we're getting a stream of corrections to the AOO 3.4.0 translations. This is not surprising. Errare humanum est. Even repetitive data transcription tasks can have a 5% error rate. That's why where accuracy is important we have consistency checks, for example checksum digits in credit card and ISBN numbers. That's why we do QA with code. That is why we have spell checkers. It is almost guaranteed that a solo translation will have a higher error rate. What can we do about this? Maybe we can promote the availability of a new translation, with help from the translator, among our user base. So notices on Twitter, blogs, and native-language tech sites. Invite users to download snapshot builds with the goal of verifying the localization. If a translation is worth doing we should be able to find a community (even a small one) of users to help with this work. Any other ideas? Regards, -Rob While lots of correction for the Spanish translation came just by checking the error tags on pootle (there is a way to go still...), a really impressive number are from direct interaction with forums users and volunteers, so I fully agree with all you said: by providing easy ways to share the user's concerns, helping them to participate, the results will always be good. But a common problem on open projects is the difficulty to find volunteers willing to spend some time not only checking the software (after all, checking is not different from using), but also *reporting* their findings: bugzilla in not for normal users and asking someone to register on a mailing list just to report a typo is a bit too much. So the challenge is to find paths to report translation problems on which normal users can feel comfortable. In my experience forums are a very good way, but we do not have (and probably will never have) forums for all localizations. Providing localized builds early on the development process (weeks or even a month before everything freeze) would be a big help on this process. But we also need to provide accessible channels, both to advertise those builds and to report the findings. One consideration about the early NL builds: we cannot ask our casual testers to make a full install of a beta software on a production machine. I think we should provide these early builds as all in a folder packages, just like the arc tarballs provided by the Linux build bot. Regards Ricardo Users also dont understand the software cycle. So translation teams have traditionally struggled with builders and QA teams to be able to fix the problem and Re-Release the build. Waiting for the next release is NOT a good answer for users or something a suser would understand. This is why translation eventually was projecting to do a more real time fixing. Continous l10n ws a project to fix this somewhat. http://wiki.services.openoffice.org/wiki/ContinuousL10n Crazy idea. Would something like this work: 1) We do a one-time effort of getting screen shots of all dialogs and other localized UI elements. 2) In Photoshop or Gimp, remove all the localized text 3) Take PO files and have a script generate a set of HTML pages that display each of the UI screen shots, with the translated text displayed in place. 4) HTML could also have links for each image that pre-populates a new BZ issue to ease reporting of issues. Is anything like this possible? Benefits would be: 1) No need to wait for a build 2) Translation testers don't need to install a possibly unstable dev snapshot build 3) Lowers the technical barriers to verifying translations. I like your idea of doing continuous integration via language packs as well. -Rob Unfortunately this project got halted but the needs are still there and the conversations are still unsolved.
Re: [Proposal] Guidelines for list conduct policy
On Tue, Jun 19, 2012 at 7:51 PM, Wolf Halton wolf.hal...@gmail.com wrote: On Tue, Jun 19, 2012 at 7:42 PM, drew d...@baseanswers.com wrote: On Tue, 2012-06-19 at 16:21 -0700, Kay Schenk wrote: On Tue, Jun 19, 2012 at 3:33 PM, drew d...@baseanswers.com wrote: On Wed, 2012-06-20 at 00:14 +0200, RGB ES wrote: 2012/6/20 drew jensen drewjensen.in...@gmail.com: List Conduct Policy 1. What Happens on the list, stays on the list: Anything you read in the private list is by default a private PPMC affair and not to be spoken of, or copied to, other people who are not in the PPMC. If you think about it, most topic threads probably should be in the public lists, except choosing committers and PPMC members, and a very few other topics. In fact, all email lists or email conversations have this aspect of privacy. Even if there are 23000 subscribers on the list, it is assumed that privacy will be maintained and a list member's name and location will not be disclosed in some public venue where personal privacy is not expected, such as published in a newspaper or some other. hi, I would disagree with that last statement completely - a public list is just that, public, and there should be absolutely no expectation of privacy whatsoever. To pretend otherwise is simply to lie to those who would use the list. //drew Point one refers to the private lists, I think. Maybe add a point zero with an introduction to the mailing lists, as Ross asked? Not a detailed introduction, just to say most lists are public but one is private. Then the code of conduct can be separated on a general part that apply to all lists and a second part with additional rules (for instance, the privacy one) for the private list. Ricardo OK if that is really just about private lists, but the last sentence read to me as if it was broader. Anyway - to be honest I find the whole subject rather silly. Does anyone really need to be told that what happens on a private list is by definition to be held in confidence? //drew Well, Drew, I think this is why this whole discussion started. Most of us would think the answer to your question is no, but, well, apparently there was some looser interpretation that some felt needed clarification. Not at all - someone violated that trust, everyone knew it was wrong, there didn't need to be rules written for folks to know that. But that is just my opinion of course. Anyway, Wolf, this is really good. I think this would be better posted as just a link on the project site, http://incubator.apache.org/openofficeorg/, under the Mailing Lists link, and give more clarification on item #1 that this most importantly applies to private mailing lists. Drew's right that we don't want to mislead people to think anything else is private. I think maybe it's a bit lengthy to add to a welcome message to list subscribers. The #1 entry is the most reactionary meaning it is in reaction to an event or events which we as a group never want to see again, and such is probably a dangerous step toward totalitarianism. I, and others have defanged it somewhat. I know it needs to be clarified to limit its scope to only the private lists or specifically the PPMC list and Security list. Maybe that paragraph should be #7 and something else should be at the top, as there are only a small percentage who are members of the PPMC/Security and a lot more who are part of dev@ or Users@ or marketing@ etc.. -Wolf -- This Apt Has Super Cow Powers - http://sourcefreedom.com Open-Source Software in Libraries - http://FOSS4Lib.org Advancing Libraries Together - http://LYRASIS.org Apache Open Office Developer wolfhal...@apache.org Here is the adjusted version: I put Dave's #7 as #0 and a reminder of the AOO mission and implications thereof as #1. The private-lists entry is now at the bottom. -Wolf +++ List Conduct Policy 1. Respect one another: Discussion is the cornerstone of a project like this and the sharing of viewpoints is crucial, as is understanding and accepting that many views will differ from your own. By all means debate rigorously and defend your view point stoutly, but avoid abrasive dialogue and personal attacks. Give leeway to people who do not have English as a first language. Pause before taking insult, and pause before responding. There is a difference between robust discussion and steamrollering. Civility is paramount. Manners cost nothing; we are all capable of self-moderation, and of being aware of our conduct. 2. Remember the Apache OpenOffice Mission: “To create, as a community, the leading international office suite that
RE: Draft Blog Post: 5 Million Downloads of Apache OpenOffice
+1 Nice one. - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Tuesday, June 19, 2012 19:15 To: ooo-dev@incubator.apache.org Subject: Draft Blog Post: 5 Million Downloads of Apache OpenOffice https://blogs.apache.org/preview/OOo/?previewEntry=5_million_downloads_of_apache The numbers stand at 4,994,262. So we'll hit 5M before I wake up tomorrow. The post announces that and then gives a general project update, concentrating on 3.4.1 and the Symphony merge discussion. It then ends with a general call for volunteers. Is there anything else we want to include? -Rob
Re: [Call-for-Review] Some issue about memory leak in Aoo3.4
The second batch for memory leak issue has been delivered yet. Thanks for Herbert and JianFang's review. goog_371113529https://issues.apache.org/ooo/show_bug.cgi?id=120019 https://issues.apache.org/ooo/show_bug.cgi?id=120021 https://issues.apache.org/ooo/show_bug.cgi?id=120028 2012/6/15 Chao Huang chao.de...@gmail.com hi, all I'm Huang Chao from China. My interesting areas are Mac porting, performance(startup, loading, saving, etc), stability, build env. At recent stage, I will focus on memory leak issue in Aoo3.4. Here are the fixed for memory leak defects I opened. Please confirm them and review them. I will continue to work on this area. Thanks! https://issues.apache.org/ooo/show_bug.cgi?id=119991 https://issues.apache.org/ooo/show_bug.cgi?id=119992 https://issues.apache.org/ooo/show_bug.cgi?id=119996 https://issues.apache.org/ooo/show_bug.cgi?id=119997 Please note that the patches for bug119996 and bug119997 are on the same source file. -- Best regards, Chao Huang -- Best regards, Chao Huang
Re: Approaching 5M downloads
On 6/19/12 9:57 PM, Marcus (OOo) wrote: Am 06/19/2012 07:37 PM, schrieb Rob Weir: We're at 4,922,774. So we should hit 5M late tonight or early tomorrow morning (UTC). I'll work on a blog post highlighting that milestone and give a general update on what we are working on. After that I plan to stop reporting on each 1M increment. They come too quickly. Yeah, it's seems indeed very quick. Maybe an update every 5M in the future? What about 10M as next step? which means in this case every 5M ;-) LOL Juergen Marcus
Re: svn commit: r1351633 - in /incubator/ooo/trunk/main: instsetoo_native/util/openoffice.lst solenv/inc/version.lst sysui/desktop/productversion.mk
On 6/19/12 10:07 PM, Marcus (OOo) wrote:
Am 06/19/2012 12:00 PM, schrieb j...@apache.org:
Author: jsc
Date: Tue Jun 19 10:00:15 2012
New Revision: 1351633
URL: http://svn.apache.org/viewvc?rev=1351633view=rev
Log:
119977: update version number to 3.5
Modified:
incubator/ooo/trunk/main/instsetoo_native/util/openoffice.lst
incubator/ooo/trunk/main/solenv/inc/version.lst
incubator/ooo/trunk/main/sysui/desktop/productversion.mk
Modified: incubator/ooo/trunk/main/instsetoo_native/util/openoffice.lst
URL:
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/instsetoo_native/util/openoffice.lst?rev=1351633r1=1351632r2=1351633view=diff
==
--- incubator/ooo/trunk/main/instsetoo_native/util/openoffice.lst
(original)
+++ incubator/ooo/trunk/main/instsetoo_native/util/openoffice.lst Tue
Jun 19 10:00:15 2012
@@ -4,15 +4,15 @@ Globals
{
variables
{
-SERVICETAG_PRODUCTNAME OpenOffice.org 3.4
-SERVICETAG_PRODUCTVERSION 3.4
-SERVICETAG_PARENTNAME OpenOffice.org 3.4
+SERVICETAG_PRODUCTNAME OpenOffice.org 3.5
+SERVICETAG_PRODUCTVERSION 3.5
+SERVICETAG_PARENTNAME OpenOffice.org 3.5
SERVICETAG_SOURCE {buildsource}{minor}(Build:{buildid})
SERVICETAG_URN
urn:uuid:500061aa-5666-11e0-8e00-080020a9ed93
BTW:
IMHO another nice example to get rid of old and no longer needed code:
The Service Tag [1] implementation from what has Sun included.
It's very simple:
We don't want any registrations -- so we don't need Service Tags anymore.
good catch Marcus, we should check where this variable are used and
should clean up the code.
It can be a good opportunity work for somebody who want to do the first
steps with the code. OpenGrok to search where the variables are used +
understanding what's going on + some editing + building + testing
Volunteers are welcome and questions will be answered here on the list
or on IRC
Juergen
[1]
http://www.oracle.com/technetwork/articles/javase/productregistration-142210.html
My 2 ct.
Marcus
Re: [RELEASE][3.4.1]: Include only one en-US dictionary extension
On 6/20/12 12:15 AM, Dave Fisher wrote: Sent from my iPhone On Jun 19, 2012, at 9:19 AM, Ariel Constenla-Haile arie...@apache.org wrote: On Tue, Jun 19, 2012 at 10:01:10AM -0400, Dave Fisher wrote: But none of you are native English speakers. English varies from country to country around the world. Why not disable or rename the second version when the name collides? we cannot edit the extensions, they are downloaded and packaged as is. On the other hand, the dict-en.oxt is a general dictionary extension, it supports the following locales: en-GB en-US en-ZA en-AU en-CA Would it be possible to reject extensions where the name collides inside of AOO? probably yes but a lot of work to workaround a bug in an extension. From my perspective not worth the effort at the moment. Config items can be overwritten by extension and the extension deployment mechanism have no clue for what the config items are used. Perhaps a description of why the extension manager chooses the bad NZ over the preferred and correctly named versions? Is the last or first with the name chosen? Would a known bad actor patch work? without checking the details, I assume the last extension who write the config item wins. The proposed solution effects many more users than are experiencing the problem. I see no real problem here. After all we are adding en-GB in this version. I am not sure if I understand you here. The dict-en.oxt included en-GB already, we include only the extension. Another solution would be to include a dictionary for en-US only in the en-US version, a en-GB only in the en-GB version and let all other en-* locales install via extensions later. But for this solution we would need clean dictionaries for en-US and en-GB only. Anyway cleaning up the current situation and including dict-en.oxt only is probably the best solution we can provide short term Juergen Regards, Dave Regards -- Ariel Constenla-Haile La Plata, Argentina
