Re: Propose Khmer language in download page
On 6/25/12 6:47 PM, Jürgen Schmidt wrote: we currently provide only full install set for the languages that we releases or plan to release for 3.4.1. But we are open to support more languages when we notice and see a working translation community for a language. That means ideally not only 1 person but a group of people who can actually review the translation ... Hi Juergen, The translation of OpenOffice to Khmer is done since 2004 by a group of professional localizers hired by the Open Institute (a local Cambodian NGO). Sokhem has been managing this group since 2005. The NGO works with the Cambodian government on the migration of OpenOffice, and mostly with the Ministry of Education, which has made OpenOffice in Khmer compulsory in Education (MS is not allowed in schools). We have always worked directly using .SDF files, not using Pootle, mostly because we were using XLIFF files instead of PO to localize, as it is much more efficient. We developed our own XLIFF editor (WordForge). Having Khmer included in the list and having a 3.4.1 installer would be great for us, as the gap since 3.3 has already been to long. The translation in Pootle will be completed within this week. Cheers, Javier We can include a Khmer language pack for the upcoming dev snapshots for 3.5 to help you verifying the current state of the translation. Juergen
Re: The reason I removed the program called Open Office 3.4
For most of our customers, how computers work inside is magic... they do not want to know how it works. Entering into a setup page is a crazy thing to do, the computer will surely break down. For them, if double clicking in the file does not go to where it went yesterday, what is broken is the application (you broke my MS Word, it does not work any more). They do not know any other way to access that application. In migration processes, you have to install the new applications and then manage the change process. Forcing change from one day to the next might fully break the process and the migration will fail because the new application will be rejected by users who have not yet been trained. In my opinion AOO needs to have (even for legal reason, maybe) the user click on something that says that they accept the associations (or not) as it used to have. For silent installation, there should be an option to do it or not. I think that the idea of allowing the change from the application itself is very good. Users like to use the application... not mess up with the system. Cheers, Javier On 6/6/12 7:07 PM, Shenfeng Liu wrote: One more question is: what's the behavior in 3.3? In my desktop, doc was auto-associated to AOO 3.4, but not ppt or xls. It does not look like an intentional design. If it is just a regression, I will suggest to simply rolling back to 3.3 for now. - Simon 发自我的 iPhone 在 2012-6-6，17:07，O.Felkaolaf-openoff...@gmx.de 写道： Am 06.06.2012 10:33, schrieb Shenfeng Liu: Juergen, Agree with you! My personal opinion is that it must be an explicit place for user to choose the file association, in installer, or option dialog... Well, we need UX experts here... We should be aware that file association written by the Options dialog won't be removed by the setup. The setup doesn't know the registry keys written by the application. Groetjes, Olaf - Simon 2012/6/6 Jürgen Schmidtjogischm...@googlemail.com On 6/6/12 4:17 AM, Shenfeng Liu wrote: As I remember, it is the 2nd customer complaint we got on this issue. And some of us (e.g. Jihui) has confirmed it. If that's the case, my question is do we have a defect id to trace it? If no, let's create one. And I will suggest it as 3.4.1 must fix. an issue is good but we should be careful and should define a potential new default in detail. How exactly we want define the new default, having 2 complaints is not much compared to thousand of Windows users. I don't say that we shouldn't change it but we should be clear of what we are doing. We can't change things every time when 1 single person don't like the default. Juergen
Re: [RELEASE] Dictionary extensions
Dear André, can you please include the Khmer (km_KH) dictionary for Khmer language. Please use the one in: http://extensions.services.openoffice.org/en/project/km_spellchecker Cheers, Javier On 3/29/12 8:49 PM, Andre Fischer wrote: Current Status: Bundled dictionaries for ui languages: ui languagedictionaries da da de_AT de_AT de_CH de_CH de,de_DE de_DE, de_AT, de_CH, it, fr, en en en, en_CA, en_US, en_AU, en_ZA, en_NZ es es fr fr it it nl en_US, fr, de_DE no no ro ro ru ru, en_US, de sl sl Find details at [1]. If a language is not listed in the first column then no dictionary will be bundled. Ongoing: Italian team is working on the set of dictionaries to include for it. _Call for Action:_ If your language is missing in this list, or you want more dictionaries bundled for it then please reply to this thread. It will not take much of your time. Best regards, Andre [1] https://cwiki.apache.org/confluence/display/OOOUSERS/Bundled+Writing+Aids
Re: consolidation of Windows Build software requirements
On 9/23/11 2:55 PM, Oliver-Rainer Wittmann wrote: I am not recognizing in my mind which service packs are available for which Windows version. I am only repeating Martin here thinking that SP2 was the latest SP for Win XP. Thus, no reason special reason for Win XP SP2. My opinion is that we should always rely on the most updated version of an operating system which we want to support. Thus, for Windows XP it should be Win XP SP3, if this is the most updated version. Well... Sp3 has a nasty side effect. You might remember that MS introduced a change that made desktops black for software that they considered as not original. Sp2is still widely used and installed in low specs computers in developing countries where no licensed copies of MS exist (and where the use of unlicensed copies of software is not illegal). These computers are a part of OOo's market. In any case, I do not think that SP2 and SP3 will be very different. Cheers, Javier
Re: consolidation of Windows Build software requirements
On 9/23/11 4:39 PM, Tor Lillqvist wrote: Sp2is still widely used and installed in low specs computers in developing countries where no licensed copies of MS exist (and where the use of unlicensed copies of software is not illegal). These computers are a part of OOo's market. Sorry if I am missing something, but why wouldn't these people use an unlicensed copy (cracked if necessary) of the real thing, i.e. MS Office, then, if it is not illegal? Imagine trying to convince them to use OOo: OK, I see you are using an unlicensed copy of Windows, oh well, that is legal in your country, and MS is evil anyway, so I don't mind. Now, look at what I have here, lovely office software which is almost as good as MS Office, and it doesn't cost anything! And it is Open Source! Don't you want to use it, please? Please? Hi Tor, Yes you are missing something ;-) You are assuming here that MS Windows is better than OpenOffice. In this case it is a wrong assumption. In Cambodia, for example, OpenOffice is in the local language (Khmer), it has a nice spell-checker, sorts words correctly in Khmer, uses Khmer dates, and it is mandatory in the education system. Why would you want to use MS Office in English (sorry, no Khmer, formats or spell-checker) in your Windows XP SP2, when you can use a program that it is easy to learn, it is in your language and it helps you write? ;-) Cheers, Javier --tml
ICU (was Hunspell and MPL license)
If I remember correctly and unless it has changed, some patches were applied to ICU during the build. This required a specific version of ICU to which the patches were applied, and this is why the ICU source was kept inside the OOo source (I believe). Javier Pedro Giffuni wrote: Hello Eike; I think you are right. I should mention that on FreeBSD, LibreO uses the preinstalled hunspell package so using the upstream version is possible already. Furthermore, we should use the same approach for ICU and other dependencies: if the system already has such packages, why not use them? I guess there may be problems for specific platforms like Windows, so there's where the binary and NOTICE files kich in. Cheers, Pedro. On Tue, 19 Jul 2011 20:41:46 +0200, Eike Rathke o...@erack.de wrote: Hi, I was digging a bit into 3rd party licenses for the Hunspell issue and came across Category B: Reciprocal Licenses in http://apache.org/legal/3party.html and noted that Hunspell is tri-licensed also under MPL 1.1 that would be permissive as long as the code is distributed only in binary form and the NOTICE file labels its reciprocity, if I understood correctly. Currently OOo needs Hunspell in source code form only because very few patches are applied to be able to build it on Solaris, Windows and MingW, and one patch against a stack smasher. Am I right in assuming that if Hunspell adapted the upstream version such that these patches were superfluous, then AOOo would be able to build against a system Hunspell or on systems where Hunspell is not available or for binary distributions a build could include a binary of the library if the proper NOTICE entry is provided? To me this sounds like a solution to the problem. Eike
