Re: [PROPOSAL] Create ooo-l...@incubator.apache.org
Il 02/07/2012 23:19, Andrea Pescetti ha scritto: Rob Weir wrote: I suggested this on the list a few weeks ago. I'd like to now move forward with it. I'll volunteer to be one of the list moderators. But I need 2-3 other committers to volunteer as well. Let me know if you can help. I can help (with my usual Apache alias, pescetti), unless Paolo Pozzan, who is more into localization than I am, prefers to be involved; in that case I'll leave this task to him. As for the timezone, I'm usually in Europe. +1! I will go for aoo-l10n. One don't need to guess the mailing list address, it is simply written, ready to be copy-pasted or clicked on it. I am also offering myself as a moderator. paolopoz is my Apache alias. CE(S)T timezone. Paolo
Re: [Marketing][UX] Who wants to do a Content Experiment?
Il 08/06/2012 15:54, Rob Weir ha scritto: A Content Experiment is when we create several version of the same web page and test it with users to see which version performs best. Google Analystics has a feature where it can run such experiments for us automatically, tracking all the statistics for us, and telling us which version of a page gives the optimal results. One particular scenario I think we could really improve on is what I call the Windows Unrecognized ODF File scenario. It goes like this; [cut] So here is the experiment. Let's try to get a handful of alternate destination pages that speak to this scenario and provide the information that would be most useful to this kind of user. It could be a modified version of the download page. It could be a new intermediate landing page that provides context and then links to the existing download page. Whatever you think would work best. We can then run the experiment, say for a month, letting Google randomly present users with the various alternate pages and measure what the download %'s are for each version. The winner will gain eternal fame and glory, maybe even a blog post. I'm willing to do the technical work on setting up the experiment and prepping the website to support it. What I need are volunteers to come up with alternate landing pages for this scenario, ones that we can include in the experiment. Do you also have statistics of where in the world this referrals come from? It will surely help users to have that page in his/her own language and I think it wouldn't be difficult to set this up with what we already have. You talked about IE6 but from what I can see here [1] english speaking countries are not on the top list. About other kind of pages to Content Experiment them, do you need an HTML, a mock-up, just the basic concepts or what? I can work on creating some alternatives. Paolo [1] http://www.ie6countdown.com/
Re: Dealing with a large and diverse project - Native Languages and project teams
Il 20/05/2012 21:25, Dennis E. Hamilton ha scritto: I want to encourage all that you say here. I am not so confident that the openoffice.org approach (that is, what Sun allowed and supported) is applicable here because the ASF as a foundation must operate differently than a commercial enterprise. That can be a minor thing, once the guidelines are clear. Do you have suggestions on how affiliation with ASF and the Apache OpenOffice project can be reconciled? Need there be any? If there is coupling between an NL community and AOO, what arrangement do you request? Of course there is no need to do exactly what Sun did, just take what we miss. There are already good examples of working local communities, so that is a good starting point. While some communities may have their organizations, I don't think there is need to affiliation at this point. Everything can be managed inside Apache OpenOffice project. Paolo
Re: Dealing with a large and diverse project - Native Languages and project teams
Il 18/05/2012 16:55, drew jensen ha scritto: Hi, Recently there has been some discussion on the projects private ML regarding issues about native language groups and how best to support work groups which will by definition be somewhat circumscribed from the whole by virtue of language without losing the cohesion of a single project focus. I invite others pick that up here: Reading to all other messages in this thread, I think many missed the point. The problem is not about what language to use, but how to manage the to-be-volunteers which don't or wouldn't have the same skills as ours. Volunteers are a big marketing weapon; is like happy workers that freely advertise the company they work for. OTOH rejected volunteers (even for difficulty of access - e.g. language) will feel the final product less theirs, so they will be less willing to marketing that. Like many opposers of AOO Project (incubating) (get it? ;-) say, the Apache Software Foundation has a long history of successful software for skilled technical users. I bet that the average OpenOffice user don't even know what a programming language exactly is, so I think this is a new exciting challenge for the Apache folks. What I understood in my experience with italian volunteers is that people love to contribute in a hassle-free maneer, this means that someone else have to show them the way, letting them just do. I know this may sound disappointing, but it is not a limit of freedom if someone choose by his/her own to follow some rules. I think that it would be useful to write some basic guidelines for the native language teams to know what to do and what not. Letting them know it would eventually lead to the birth of local communities, where basic contributors will eventually will go there. Maybe many of us have still in mind the old OpenOffice.org structure, which worked fine for the language teams and to which we can consider copying from. Paolo
Re: Dealing with a large and diverse project - Native Languages and project teams
Il 20/05/2012 20:57, Paulo de Souza Lima ha scritto: 2012/5/20 Wolf Haltonwolf.hal...@gmail.com On Sun, May 20, 2012 at 2:43 PM, Paulo de Souza Lima paulo.s.l...@varekai.org wrote: 2012/5/20 Paolo Pozzanpa...@z2z.it Reading to all other messages in this thread, I think many missed the point. The problem is not about what language to use, but how to manage the to-be-volunteers which don't or wouldn't have the same skills as ours. Volunteers are a big marketing weapon; is like happy workers that freely advertise the company they work for. OTOH rejected volunteers (even for difficulty of access - e.g. language) will feel the final product less theirs, so they will be less willing to marketing that. Like many opposers of AOO Project (incubating) (get it? ;-) say, the Apache Software Foundation has a long history of successful software for skilled technical users. I bet that the average OpenOffice user don't even know what a programming language exactly is, so I think this is a new exciting challenge for the Apache folks. What I understood in my experience with italian volunteers is that people love to contribute in a hassle-free maneer, this means that someone else have to show them the way, letting them just do. I know this may sound disappointing, but it is not a limit of freedom if someone choose by his/her own to follow some rules. I think that it would be useful to write some basic guidelines for the native language teams to know what to do and what not. Letting them know it would eventually lead to the birth of local communities, where basic contributors will eventually will go there. Maybe many of us have still in mind the old OpenOffice.org structure, which worked fine for the language teams and to which we can consider copying from. Paolo That's exactly what is happening to brazilian community. The most of us have not technical skills. But we are AOO users and we have influence to convince many people and organizations to give a chance on AOO. And we are being striked a lot because of that, but we are standing still. -- Paulo de Souza Lima http://almalivre.wordpress.com Curitiba - PR Linux User #432358 Ubuntu User #28729 Paulo, I am not sure I understand either. What is missing that would make it easier for you to do what you want to accomplish? Maybe is about what must be missed. Asking a volunteer to subscribe to a mailing list with hundreds of messages in a month can be very frustrating and also annoying. Hi Wolf. Nothing at all, actually. It would be good if we had a pt-br mailing list, but we are using a mailing list from Escritorio Livre Community. The most important for people up here,maybe, would have support and acceptance from AOO without many bureaucractic issues. We are proud to help and we help for fun, without political or economic interests. I think this could lead to a polemic discussion and I don't wish to be polemic. Sorry. Paulo, as long as you are looking for a way to get better processes you cannot lead to polemic discussions. Let's find a solution togheter. Paolo
Re: [RELEASE][3.4.1] propose following tasks for updating the translation
2012/5/11 Jürgen Schmidt jogischm...@googlemail.com: Hi, I propose the following tasks for 3.4.1 Integrate updated translation - Finnish - https://issues.apache.org/ooo/show_bug.cgi?id=119329 - British English - https://issues.apache.org/ooo/show_bug.cgi?id=119330 If it is not too time consuming please do it also for italian, taking the files from pootle. We made some small fixes after the 3.4 integration. Thanks. Paolo
[L10N] Plans to merge again Pootle content?
Hello, I made some changes to the italian translation available in Pootle. I wonder if there is any other planned import to the source before the final release. I will probably add more enhancements to the translation so it will be useful to have a schedule. Thanks! Paolo
[TRANSLATION] translated italian files for 3.4
I opened a bug with the files attached: https://issues.apache.org/ooo/show_bug.cgi?id=119173 Paolo
Re: [TRANSLATION]: Current status
Il 29/03/2012 13:24, Jürgen Schmidt ha scritto: Hi, the Pootle server is now updated and in sync with the latest available translation data and the new 3-4 relevant templates. [cut] I tend to include these languages in our first release and plan to take the available data from Pootle on Monday. That means every update that is available until Monday (April 4th) will be integrated. You can also attach local translated po file to a new issue and assign it to me. I need to send you the files for italian translations. Can you please remind me what is your BZ username? The relevant projects can be found under UI: https://translate.apache.org/projects/OOo_34/ HELP: https://translate.apache.org/projects/OOo_34_help/ Right now there is a general problem on the Pootle server that suggestions can't be accepted or declined. Even when the permissions are set correct (I have the same problem in my local installation of Pootle). But it can be workaround by copy the suggestion manually. Not perfect but it works. In such cases I would suggest the committer who plan to accept something search the dialog on the mailing first or however it is managed by the people who work on it in a shared team. I would say we will need at least 1 committer for every language. That's why I send a signed ICLA to the foundation. What are the next steps I should follow to become committer? Thanks. Paolo
[Translation] Re: CVE-2012-0037: OpenOffice.org data leakage vulnerability
The italian community would like to translate the bullettin. It will really help us to have the originals ODT versions of the README.pdf files. Can someone provide them? Thanks Paolo Pozzan Il 22/03/2012 14:16, Rob Weir ha scritto: Please note, this is the official security bulletin, targeted for security professionals. If you are an OpenOffice.org 3.3 user, and are able to apply the mentioned patch, then you are encouraged to do so. If someone else supports or manages your desktop, then please forward this information to them. Additional support is available on our Community Forums: http://user.services.openoffice.org/ And via our ooo-users mailing list: http://incubator.apache.org/openofficeorg/mailing-lists.html#users-mailing-list Note: This security patch for OpenOffice.org is made available to legacy OpenOffice.org users as a service by the Apache OpenOffice Project Management Committee. The patch is made available under the Apache License, and due to its importance, we are releasing it outside of the standard release cycle. -Rob -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 CVE-2012-0037: OpenOffice.org data leakage vulnerability Severity: Important Vendor: The Apache Software Foundation Versions Affected: OpenOffice.org 3.3 and 3.4 Beta, on all platforms. Earlier versions may be also affected. Description: An XML External Entity (XXE) attack is possible in the above versions of OpenOffice.org. This vulnerability exploits the way in which external entities are processed in certain XML components of ODF documents. By crafting an external entity to refer to other local file system resources, an attacker would be able to inject contents of other locally- accessible files into the ODF document, without the user's knowledge or permission. Data leakage then becomes possible when that document is later distributed to other parties. Mitigation: OpenOffice.org 3.3.0 and 3.4 beta users should install the patch at: http://www.openoffice.org/security/cves/CVE-2012-0037.html This vulnerability is also fixed in Apache OpenOffice 3.4 dev snapshots since March 1st, 2012. Source and Building: Information on obtaining the source code for this patch, and for porting it or adapting it to OpenOffice.org derivatives can be found here: http://www.openoffice.org/security/cves/CVE-2012-0037-src.txt Credit: The Apache OpenOffice project acknowledges and thanks the discoverer of this issue, Timothy D. Morgan of Virtual Security Research, LLC. References: http://security.openoffice.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCgAGBQJPayGmAAoJEGFAoYdHzLzHJVcP/jXzY+ROwPTAaSItCc4GAn2q Gm3uL9D9aRrs/pp+sofRkF9L3nyWEyyVfvZv6+IBrqOU/2Tu1CD8cY6Kns1ZYxVO ZRDiR5hhr3pA6KfWlb9W9it/8JsTF7WZfTX0uRMPXCYlJuYQ38Nl7kloPYswXG2w By2J19VanlHuwLQJoNV08652HBDy2Xpa6Wk7N5NoyETILOS47QTgizjAYZ2AY0GE ykBFu9A9yblLM5zftuMT/4FxkHQ8Qx5I3NmV3V8cUgJlmbc2oscsC23iIPcoulJF GSn8tub/e47xzgpJy69NoHgzmb6Ou+J3BDXr0kmH008P6FaTpTgPTltZ8Fcua+T2 JSWjzW5IBOW/20J9RN+5lkDJQTY5FiqqpjV7H6bZV3+MVx3Fk/ih1uJPr2cVZqaT pDU5xtn79py7MNsmpjnzD7mPbdiA2OfStzFpqUM60HOki7RgGpozvUPEvA0uIss9 X/jP1KixPDdbGS2fMrM7KG9mnT8BOzwow0Vti7alP2x2BkTXZm2K/qflXJDFCxTn g23OJIxlnhC8cK4etyezWNMSya4LLMgz6ZO+TEdvCSaaF6b3t6seskgnFAMcdPHY bkfzzYnACtrvQAmRQ1Nn4i1yFGAY+cTE7sUO2NcFhHn6jXaiZFEatdh4XJEEcTXl OZE/3v6XnehMD/32kipa =/qce -END PGP SIGNATURE-
Re: [TRANSLATION] First part is now at pootle
Il 21/03/2012 16:14, Ariel Constenla-Haile ha scritto: Hi Jürgen, * On Wed, Mar 21, 2012 at 08:48:55AM +0100, Jürgen Schmidt wrote: Hi, excuse my top posting. It is not yet clarified how or if we can ensure the translation from non committers. You should have noticed that we at Apache take some things more serious than others. The easiest way is to get access to the language you want to translate is to become a committer. Maybe we find another solution but why not becoming a committer? The first step is to sign a iCLA (http://www.apache.org/licenses/icla.txt) and send it back to Apache. If you can work with offline tools feel free to contact me or Raphael and we will help to provide a set of po files. The I guess most people will want to work off-line, at least I count three people on the Spanish mailing list willing to help translating. There should be a way to download the po files without needing to contact you directly. I confirm that working offline is usually preferred. Many useful functions like translation memories and terminology are not available in pootle while they are common in offline tools. Paolo Pozzan
Re: [TRANSLATION]: Request for translation and effort estimations
Speaking for italian... (see below) Il 21/03/2012 15:11, Jürgen Schmidt ha scritto: Hi, the Pootle server is updated to the latest resource strings and a first set of languages is provided. At least for the UI, help is in progress. The available languages are the languages where we have already provided developer snapshots, means languages where we got feedback so far. We all know that more languages would be better and we will add more languages on demand... But I would like to ask our translation volunteers what do you think when we will be able to have a complete translation. Or better I would like to ask the following questions 1. Do we have volunteers for the currently available languages, see [1]? We have a bunch of volunteers who have already given their availability for this job. 2. Can we get a rough estimation when we can expect a 100% translation 2.1 for UI? One week, more or less. 2.2 for Help? Usually the amount of work for help is greater than UI, but I don't know if this is the case. We need to see the files to make an estimate. [cut] Paolo Pozzan
Re: [Translate] Users for Pootle Server
2012/3/11 Gavin McDonald ga...@16degrees.com.au: -Original Message- From: Paolo Pozzan [mailto:pa...@z2z.it] Sent: Sunday, 11 March 2012 7:02 AM To: ooo-dev@incubator.apache.org Subject: Re: [Translate] Users for Pootle Server Il 09/03/2012 22:22, Rob Weir ha scritto: On Fri, Mar 9, 2012 at 6:30 AM, Michael Bauerf...@akerbeltz.org wrote: [cut] 2) Allow account creating as on other Pootle servers without any hoops to jump through other than the usual signup process. In essence, handle Pootle and l10n as it was handled before. Most of us are not familiar with how it was handled before, so it is good to discuss the details, so we all understand it. Right now it is configured so all Apache committers can login and have review and commit rights. Non-logged in users (everyone else) can view, suggest and submit translations. It's not useful to give causal contributors write access to translations: they usually don't know what writing style to follow and don't know the correct terminology. This will only mess up things or give more work to do to the translators. Please don't let submit rights to non-logged users. In your mind, what do you think 'submit rights' mean? I mean the right to push the submit button of the pootle interface when trying to modify a string. This leads to overwriting the previous translation. To me it means submit a translation for approval by a committer, without such approval it does nothing and harms nothing. Why are you against such actions whilst the rest of the people in this thread are trying to open up access even more? You are talking about the suggest feature (and button). Right now anybody can overwrite the translations without logging in at all. I am favorable to open up access but only to translators, not everyone. Paolo
Re: [Translate] Users for Pootle Server
Il 09/03/2012 22:22, Rob Weir ha scritto: On Fri, Mar 9, 2012 at 6:30 AM, Michael Bauerf...@akerbeltz.org wrote: [cut] 2) Allow account creating as on other Pootle servers without any hoops to jump through other than the usual signup process. In essence, handle Pootle and l10n as it was handled before. Most of us are not familiar with how it was handled before, so it is good to discuss the details, so we all understand it. Right now it is configured so all Apache committers can login and have review and commit rights. Non-logged in users (everyone else) can view, suggest and submit translations. It's not useful to give causal contributors write access to translations: they usually don't know what writing style to follow and don't know the correct terminology. This will only mess up things or give more work to do to the translators. Please don't let submit rights to non-logged users. What are we missing? Would it work, for example, if the translation leads become Apache committers? I think it can work. Better yet: back in OOo days various teams were able to choose between pootle or direct SDF submission (as Claudio said). Maybe in this phase of reorganization it would be helpful for the teams to choose their preferred method. Paolo
Re: [Translate] Users for Pootle Server
2012/3/9 Michael Bauer f...@akerbeltz.org: Be constructive. What would be the top 3 things that we should change? -Rob Gladly, though I may be repeating myself :) 1) Allow some for a small number of locale leads which initially are given freely like candy but allow for revisting that if lead turns out to be inactive or rogue. These leads administer the access levels of their fellow translators (if there are any). These need Project Admin (https://cwiki.apache.org/confluence/display/INFRA/translate+pootle+service+auth+levels) access but I'm sure they'd be quite happy to have that restricted to AOO Pootle only. As I said before, I doubt a lot of translators will do much in the way of committing code. +1 2) Allow account creating as on other Pootle servers without any hoops to jump through other than the usual signup process. In essence, handle Pootle and l10n as it was handled before. +1 3) Once that basic sort of l10n infrastructure is in place, find some people skilled in code who are willing to keep a closeish look on l10n issues and decamp l10n from the main dev mailing list. +1 Paolo
Re: Please do not work at Pootle atm
2012/3/5 Andre Fischer a...@a-w-f.de: Hi Raphael, On 02.03.2012 20:34, Raphael Bircher wrote: Hi at all No panic, I will make this night a new initial import. The reason is, that we are not sure if the data from the old pootle server are compleet. So we want to be sure, and so I will import the data from the SDF. I will import only the language wich we release for the moment. I hope, i can do this work util tomorrow I am a bit confused. SDF seems to imply the current data in the extras/l10n module. For at least one language (zn-TW) we know that the data from the old pootle server is more up-to-date. How can we handle that? Usually previous translations will be merged into the newly extracted .po files, so there won't be any loss of data. It's indeed necessary to update the files to have a fully translated 3.4 release - given to find an easy way to manage pootle users and permissions. Paolo
Re: Please do not work at Pootle atm
2012/3/6 Raphael Bircher rbircher_...@bluewin.ch: Am 06.03.12 09:50, schrieb Andre Fischer: [cut] When there are strings that are in both data sets then we have to choose one, right? Is that done automatically? Usually yes, you can set automatic translation for 100% match. For this and other procedures the translate-toolkit [1] is the way to go. First at all. I have backups from the data. But yes, we have to merge changes. The problem is, that we have not realy a clean base. We have 3 different sources: - first the SDF in the Source - The backup from the old pootle Server - The Source it self (but the source has no translation, only the en-US strings) The SDF Files works in the build, so they are tecnical clean. But they are probabily not up to date with the localization. The SDF was created before Hamburg stopt working. So samewhat in the March 2011. The Pootle server works much longer, so there are probabily translation in the old Pootle backup wich are not in the SDF. But both include not the new AOO Strings. I thought the SDF were updated with AOO strings... Probably the SDF comes from the last translation round which was set up for 3.4, so all the teams that completed the translation in time probably have no difference between SDF and pootle backup. The Pootle server has a actual Backup from the translation, but this backup commes from a crushed HD. So we are not sure if this files are clean. Not clean po's are a big risk. They are a risk for build if converted in SDF, but not for creating translation memories ;-) The data from the source content the additional AOO strings but no translations. What I try to do is the following: debug the existing po from the old Pootle server. Broken language we can't use, the changes will be loost. If you have a actual local copy of the po files from the old Pootle server you can send me the directory in a Zip archive. Dreate new po files based on the AOO Source update pootle If I can be of any help (even if I have no commiter status), just let me know. [1] http://translate.sourceforge.net/wiki/toolkit/index Paolo
Re: Localization process (Re: [RELEASE]: preparation for our first release)
Il 01/03/2012 11:49, Andre Fischer ha scritto: On 29.02.2012 21:59, Andrea Pescetti wrote: On 27/02/2012 Andrea Pescetti wrote: On 27/02/2012 Andre Fischer wrote: It would help me, for example, if you could describe the localization from you POV, like how you down- and later upload data from/to the pootle server. When do you start translation, how do you signal that you have finished translating and the uploaded data is ready for integration? This is easy and I can answer it too: Sun/Oracle used to prepare the data from the sources and uploaded them to a Pootle server; then translation teams would operate on the PO files (online or offline) before an announced translation deadline; at that point, control was back in the hands of Sun/Oracle: they used data from the PO files to repopulate the SDF files used in the source. But this probably adds nothing to what you already know: in other words, the code-Pootle conversions have always been black boxes for translation teams. Actually, the code-Pootle conversions haven't always been black boxes: what I wrote is true for recent years, but before that the translation teams delivered the sdf files directly, so we went an extra step, even though not directly to the source code. That process was managed by Paolo Pozzan, who recently joined the list, so he might provide some useful insights. Paolo, http://wiki.services.openoffice.org/wiki/Localization_for_developers contains the information we have so far. If you know more about any of the steps involved, feel free to complete it. And please don't be shy. I have no prior experience with the translation process. I just pieced together what I found in the makefiles and source code of tools. Fortunately I'm not shy, just busy with other things ;-) I added the few things I know to the wiki page. I am confident with all the processes from .sdf to translators and back. If there is a way I can help I am ready to do it, just tell me what I need to do. Paolo also has Pootle backups for Italian taken in April 2011, which means we might compare them to Andre Fischer's files http://s.apache.org/5YT (thread: http://s.apache.org/k0 ) and see if that backup is current. Anyway, we didn't update translations after April 2011, so we surely have the latest data (we = Italian translation team). That sounds great. Is your data in a form that could be checked into extras/l10n/ directly? I have the whole po files from pootle. I just downloaded the .sdf file from extras/l10n. I'm going to convert it, check the differences and then let you know. Paolo
Re: [RELEASE]: release platforms, products and languages
Il 28/02/2012 17:34, Jürgen Schmidt ha scritto: On 2/28/12 4:29 PM, FR web forum wrote: cut Languages en-US de fr es it ja zh-CN pt-BR nl More languages packs when we have verified the translations and when we have volunteers who are interested to test these languages. Means we need volunteers from the local communities who are able to test these languages. When we see enough support we can also provide full install sets. We have to figure that out over time. I am not sure right now. Actually in french, this pack is incomplete and unusable. Many strings are not translated. So, we expect Pootle and french .po file to provide a correct translation. ok, sounds not good. It seems that we have to work on the pootle stuff ... Do you have local backups or do you know if there was work ongoing for a 3.4? I know that many of the French community went to LibreOffice. Can you maybe also check the data available on http://people.apache.org/~af/ Given that with OOo every l10n team had its own workflow, I propose to populate the Apache instance of pootle server with the translatable strings of the to-be-released code, then every team should be able to easily merge the previous translations with the new one. Either way a similar process is doable with the snapshot of the old pootle in a somewhat bulkier mode. BTW, this is my first post in this list. I was the lead translator for italian OOo (and probably I will be it also for AOO). Paolo
