Scottish Gaelic
Ok, I'll have a bash at maintaining Gaelic (again) as I've heard from someone that you can do that by "proxy". The current version is full of junk so I'll start from scratch - could someone please bundle me blank po files (just AOO, not Help) for en > gb an email them or put them somewhere for download? I'll work on them and when I'm done I'll upload them and provide a link where an admin can grab them and commit them (over-writing what's there at the moment). Cheers Michael
Re: [POOTLE] Work-flow for non-committer contributors
valid concerns that I haven't taken into account yet. I learned that some translators used other tools, I am no expert here. But would be interested to learn more here as well. Juergen Depends on the team/translator. Virtaal is a popular option (http://translate.sourceforge.net/wiki/virtaal/index?redirect=1), it's a translation memory which handles po files. This is, incidentally, where this grousing over the licenses around LO vs OO translations will get a little silly because the idea of a translation memory that you don't have to re-translate strings that have been already translated and to ensure consistency. There's only so many ways in which you can translate "Open file" anyway... Michael
Re: [Translate] Users for Pootle Server
10/03/2012 08:45 sgrìobh Rob Weir 1) We know who made the contribution. This is good from IP perspective, but also from a community perspective. Contributors should get recognition for their work. If they can only contribute anonymously, this is a problem. It also hinders the PMC from recognizing active contributors and offering them committer rights. that never seems to have been a problem previously. There usually are many more translators, some who contribute only one or two translations, than can be listed. 3) We need some mechanism for a Committer to review and commit contributed translations. This doesn't necessarily mean that we must have committers that can read 110 different languages. But it does mean that we need a process that a Committer can follow to ensure that the translations are of sufficient quality to be included in a release. An example of such a process could be: a) Committer verifies the origin of the translation strings,e.g., they came from Pootle server from known contributors. That doesn't ensure anything. I could regularly contribue stuff that looks very much like, say, Navajo but no one has any way of knowing if it's good or bad if I'm the only one providing Navajo transalations. c) At this point the language strings are considered "candidates" and the committer can check the strings into SVN. They are included in dev snapshots as "candidate" translations, but they are not yet included in releases yet. That will result in very long delays cause you're in effect doing the same job twice and I can't see a language like Gaelic or Bambara being very high up anyone's list of priorities. d) We have some sort of community review procedure. We rely on native speakers to test the translations. And how do you identify native speakers? Especially for smaller languages, localization work is often done by fluent learners anyway, it's just the sociolinguistics of the small languages. We probably need a proactive RTC rather than lazy consensus. So maybe we just wait until we get 3 +1's votes from volunteers who have tested the translation. When we have that, then the translation becomes "approved" rather than "candidate". Again, that dooms small languages. How many times do I need to repeat that with all the pushing in the world, small languages usually consist of a team of 1, maybe two. If I had to wait for 2+ votes on any Gaelic localization I've been involved in, I'd still be waiting for a release. Two years on, I have a team of two who will, if they have the time, install a pre-release and do some light testing and I already consider myself lucky having them. May I ask why you're trying so hard to change a model that worked reasonably well before? Michael
Re: [Translate] Users for Pootle Server
09/03/2012 4:52, sgrìobh filh...@gmail.com: 1) Really Pootle can be useful and we can win produtivity with it, BUT is possible work with other tools too; Yes, no one is denying that. But as a "base" it's useful. I don't usually translate within Pootle myself, I export the po and work in Virtaal and the commit the file back. 2) This instance of Pootle, without a minimum of one person per language as committer, is unusable. It's not even that. Currently the model is "Anyone is a suggester, heaven knows who is a committer". That's one of the things I've been criticizing, AFAIK, there is currently no such thing as a locale leader/committer. Michael
Re: [Translate] Users for Pootle Server
09/03/2012 21:22, sgrìobh Rob Weir: OK. I think we have a volunteer project admin for the AOO Pootle project. That is Raphael, right? As an l10n admin you mean? Which would be fine. However, a single person can't realistically be admin to oversee all language projects from a linguistic point of view. While many of us can handle more than one language, there's no one that can handle all of them. 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. Which is why I suggested that the interested/involved parties sign up for accounts over on the LibreOffice Pootle server just so they see how it works. I *don't know* all the technicalities of how Pootle works either. 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. What are we missing? Would it work, for example, if the translation leads become Apache committers? This is all making localization of OO unnecessarily complicated. Looking at it another way - is there a way of separating the signup and rights management of Pootle on Apache from the rest of the rights management on Apache? All the necessary localization tools and processes are there within Pootle. The only problem we're facing is that the only signup and rights management path at the moment is via the standard Apache signup etc. We need to make the two separate. I've done you some screenshots of what a locale admin account looks like in Pootle (http://www.akerbeltz.org/Process.doc) The Overview (page 1) is, well, the overview, it shows you what projects a project admin has enabled for your locale cause not every locale does all projects. Gaelic for example isn't bothering with the Help files. Page 2, Permissions, is where a locale adming adminsiters which other registered users (the dropdown on the left) they want to assign what rights to. Pootle is very efficient here. It allows for very flexible handling of user input, ranging from pure viewing and suggesting (for folk with questionable language skills for example) to committing and overwriting. Within Pootle I hasten to add, although I can commit translations to Pootle or overwrite files does not mean I automatically have the rights to overwrite LibreOffice code. Page 3 is the Review screen which flags various issues such as missed placeholders etc. Also allows zip download of the po files (probably not to every users though, not sure, I've only ever had a locale leader account). Page 4, Overview, is where I drill down to individual po files, either to then translate strings online OR to upload a po file I've edited offline. There's more but I think those are the important bits for this discussion. The only thing we really need, the way I see it, is to keep the two rights management processes separate, then enable all the Pootle features and just go with what Pootle offers. At some point, someone picks up all the translations and ports them to wherever the black magic happens to create builds. Simples :) Salude, Michael
Re: [Translate] Users for Pootle Server
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. 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. 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. Cheers, Michael
[Translate] Users for Pootle Server
I don't think any community engagement will be too successful with the current setup. It may be that the setup has worked very well for Apache so far but looking at the list of projects (http://projects.apache.org/indexes/alpha.html) I can't really see anything that looks like a project that has a localization effort comparable to OO (admittely, I did not check them *all*). AOO seems to be quite different and has its own community history of localization if you will. Putting the two together the way they currently are feels very much like a square peg in a round hole. Michael I am sorry if this has already been discussed but I lost a few messages... With the Pootle server on-line, I plan on calling on the pt_BR community to revise and improve the Brazilian translation for AOO. User registration on Apache's Pootle server, however is manual so my question is: how should we engage the community to assist in the translation process? -- Roberto Salomon
Re: How can we get OpenOffice started with Pootle?
02/03/2012 23:41, sgrìobh Gavin McDonald: See https://cwiki.apache.org/confluence/display/INFRA/translate+pootle+service+auth+levels for more info on the privileges applied. You need not be logged in to submit translation suggestions. Therefore, no need to be a committer to do so either. HTH Gav... Gavin, the nature of the best is that for small languages, you usually have a team of one. If I add "Suggestions" then there is no-one who will accept them or, if I get the right priviledges, I have to accept them at a later point myself. Or indeed, if someone suggests a junk translation, then how will a committer who is unfamiliar with the language going to know? I'd have to be at least a Project Admin level (looking at your table (by the way, should that be "higher perms" instead of "giving higger perms"?). Not because I want to commit but apart from the above reason, because I'm not doing anything unless I can make backups (sorry, but I *almost* got burnt very badly when OOO went down) and because I need to be able to overwrite some of the old stuff (I was in the middle of a major review of a lot of junk that ended up in the Gaelic translation). If that's not an option, then I have to seriously think about participation in AOO. Michael
Re: How can we get OpenOffice started with Pootle?
This is managed over the Apache Account Management. If you are commiter, you should be able to login with your Apache ID Raphael, I'm not. Well, as far as I know. Mice can code better than me and I don't intend to commit anything but translations and the odd locale data xml at the most. And I suspect there will be a lot of people like me (eventually). Should they *all* become Apache committers? I admit to not knowing what rights exactly that bestows on a user but it sounds rather dangerous to me, giving people who are likely to only translate the rights to commit other stuff at the same time. But maybe I just misunderstood you? Michael
Re: Heads Up POOTLE data are on the way
I would vote for separating help from UI. -Andre Yes, you have my full backing there. I note that my previous proposal of "staged releases" has turned into a lead balloon :/ Michael
Re: How can we get OpenOffice started with Pootle?
The pootle server is there and was created mostly due to our request. The way to get access is to offer to help and ask for access (as Raphael has done). If you are interested in helping, offer and ask. (hmmm... and be nice to Gav, because he's probably the one from infra to give you access) A. I wasn't not being nice to anyone :) If that's the case, then someone needs to stick a note on that page cause as you may have guessed, my yarrow rods are in for repairs so I could not ask a favourably inclined deity to share this wisdom with me :b *Any* such project has a link that tells you how to sign up. But on https://translate.apache.org/ you can only login. Slightly odd though that account creation itself is manual. Normally on a Pootle server anyone can create an account but you need an admin to give you rights to do stuff on it. Nice to see that all the languages are there now though! Michael
RE: How can we get OpenOffice started with Pootle?
What do you mean by the statement "We do not have an active pootle server" ?? There is https://translate.apache.org , been up for months, please concentrate your pootle efforts in helping to get that working for your needs -- it is after all your project that asked for it in the first place !! Gav... I take it that came over more brusque than it was meant? Yes, we know that's there. But nowhere where we can sign up, as Andrea pointed out. Michael
Re: [RELEASE]: preparation for our first release
Would it make sense to make localization a more continuous process? Like adding a step to the build server to collect new strings daily or weekly, upload them to the pootle server, and integrate any newly translated strings? Regards, Andre Not on a daily basis. If you make things available for translation too quickly, there's a lot of toing in froing. Say you accidentally commit a bit of code which requires 20 new strings to be translated. Some teams will deal with that quickly and if you have to back it out 2 days later, they will have worked for nothing. So experimental stuff should not come up for translation straight away. The thing is, making changed/new strings available fast is not key really. Between releases, there's not much usually. Michael
Re: [RELEASE]: preparation for our first release
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. Regards, Andrea. Yes, that's (fortunately) been the case and should continue to be the case. And I am a developer with limited knowledge about the localization process. Maybe we can help each other. 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? -Andre Sure. There's little in a way that I need to add to what Andrea said. The black magic between the po files on Pootle and the rc / releases must remain separate from the task of translation. Pootle server is good, it allows on and offline collaboration, offline for example by downloading the po files and then editing them in a translation memory such as Virtaal which reduces the amount of re-translation. There were and are (over on LO) no "signoffs" the way Mozilla has them. There are translation deadlines and if a locale has completed a sufficient amount of the UI by that date, then there will be a release in that language. I know we had this debate about release vs language pack; that should remain in the background, all the end user wants to know is that they can get OO with the UI in their language. I'm not sure if the upload options come with Pootle or if they must be coded, i.e. you get the choice of Uploading and overwriting, Uploading and turning conflicts into suggestions etc. If they need to be coded manually, we can talk about that. If you want to, you could sign up with the LO pootle server and I can give you rights in Scots Gaelic so you can see how it works? I'm just not sure what "comes with Pootle" and what doesn't, so perhaps the first thing to do would be to get it up and running and see what that gives you, perhaps with a small number of locales that we can test stuff with? Since this is still fluid, I'd like to make an impassioned plea. We should set intelligent cutoffs (note the plural). For most localizers, the key part of OO/LO is Writer. But the localization process so far has required teams to complete x% of the total UI. This is very unhelpful and an obstacle to new locales, especially small ones. There's a possibility here of making AOO very attractive to new, small locales by introducing stepped localization i.e. we identify the strings which are in Writer and allow releases for locales which have completed just Writer, OpenOffice "light" in a sense. I know there's grey areas in between (i.e. which strings show up where) but even just excluding those which are clearly Draw/Calc/Database/Formula/Present makes localization more manageable. OO has gotten fairly big. Beyond that, ideall you simply add and additional translations to a release but if someone argues heavily for doing it package by package i.e. once you finish Draw, you also get Draw localized UI, then I won't argue. Michael
Re: [RELEASE]: preparation for our first release
Andre, Your mails arrive out-of-thread and I have no idea who wrote the sentence above. Could you check your mail client?That is a good idea. Please go ahead. The answer to your question is: I did not yet have time for it and nobody else did it. Therefore you are welcome to do it. -Andre Sorry, my emails arrive out of thread cause I get the digest and I have yet to discover a means of "replying" to specific strings. The post I was replying to was by Jürgen Schmidt. Thank you for the invitation - I'd love to but I honestly don't have the right skills. I'm a really good translator but while I have some knowledge of localization from the translator's POV, I still can't do code. Michael
Re: [RELEASE]: preparation for our first release
here we might run into a problem because of not having the translation process in place 100%. We have to figure out which translation data is the latest one, it's still not 100% clear if we really have it :-( Well, for starters, why don't we get the Pootle server up and running, enable all the languages that were working on localization at the last known date but keep all data "blank". There will be a fair number of locales who have local backups of their latest dataset before the old Pootle server went dead (I know I have) so it would be a simple case of uploading the po files again. That would solve a number of headaches and give people the chance to bring them up to date. And *then* worry about the rest. At the moment, everything is dead on the localization side and if a release is being eyed, then the longer that's dead, the worse a headache it becomes for the translators. Michael
Re: Where is Localization/Translation Now?
I assume you refer to my "leading by doing" statement. I disagree with your best case scenario. After all, this is how development is done. Are there (should there be) different rules for translators? -Andre Putting it the other way, would you give just anyone the right to commit new (structural) code? Community translation has its good sides and it's bad sides. What will undoubtedly happen is that there will be disagreements over style, terminology and orthography. Unless you have the option of making someone the "arbiter" of that locale, you end up with the most nauseating hotchpotch of style, terminology and orthography. Some of the Google interface languages are like that. It's a quality issue. If you're (AOO as a project that is) not bothered about, say, the interface switching between old and new German spelling within the same locale, one person calling the same thing a "Rechtschreibprüfung" in one menu and "Orthographiechecker" in another, then that's worrying. Michael
Re: Where is Localization/Translation Now?
OpenOffice is not owned by Sun/Oracle anymore. At Apache you lead by doing (or is that something that Yoda said?) The answer to you question is: I don't know, but probably not. Regards, Andre While I appreciate the sentiment, that's a recipe for disaster in a localization process. In the best case, you'll get some well meaning person who messes up the translations unintentionally, in the worst case, you get a troll who deliberately causes you hours of work backing out stuff or asking someone to back out stuff. Michael
Re: How many languages will Apache OpenOffice support?
When the localization ratio is not high enough (we have to define this limit), then we should only build a langpack for this language. Otherwise you have, e.g., 30% localized UI and an English-only help. This doesn't help any user. Yes, I agree that a cutoff is sensible though at present it's, from the localization point of view, hard to handle this sensibly because, even though a 50% translation may cover the strings most users use most often (i.e. Writer), it's very hard to tell which strings you should localize in. Sorry if the questions is naive but can you define a langpack language? I never took part at that level with OOO. Are those languages without localized Help? Just a question (and i have no answer) but more and more software I get doesn't use in-product Help but refers you to a Wiki etc. Might it not make sense to consider making in-product Help optional and referring to a Help website for the most part? Secondly, a more sensible, slimline install would certainly sound sense to me. It's been a while since I did the install but if I recall correctly, you actually download the English install with all the langpacks and then have to manually pick your language. Which is bonkers. If I've selected Tamil as my language of choice, then I don't need my bandwidth cluttered up with the other 50 languages. I should *only* get Tamil, with no further messing about. The full pack only makes sense if you're installing more than one language at the same time. That to me would be the two most obvious ways of saving space and bandwidth, so - Move help and other things into a separate download file. - Reduce the doubled data and libraries in the package files. - Improve the installer to download langpacks that the user wants. - etc. Amen to all of these! Michael
RE: How many languages will Apache OpenOffice support?
In passing, many smaller languages won't even try to do the Help files, so whatever % is applied for builds/releases, it should be independent i.e. 100% of the UI should result in a build/release, even if Help is at 0%. Michael
Re: [NL][Proposal] structure and process
Hi Hirano, Sorry for the late reply. 14/12/2011 12:54, sgrìobh Kazunari Hirano: I see. Why don't you propose "ooo-l...@incubator.apache.org" ? if you think it is not very good to use this list, ooo-dev@incubator.apache.org, as general l10n list. On such a list we can discuss about how to use the pootle server, po files, gsi files, translation deadline etc., right? That will be great. :) Thanks, khirano Well, at the current traffic, having fewer lists is probably ok. I was looking ahead for the time when there will be high volume lists for a range of topics, at which point I'd probably sign off the main dev list and on to l10 as that's my main concern. Michael
[NL][Proposal] structure and process
I tried to rewrite the native language page, http://ooo-site.apache.org/projects/native-lang.html, and to define structure and process of Native Language Projects within Apache OpenOffice.org (incubating) project. Is there a general l10n mailing list that we can link to from that page? I had a mailing list for my locale on OOO and that was... not lively and I think most small locale teams prefer to deal with a general l10n list. Cheers Michael
Re: Lost localisation files?
So, if you are searching for the latest strings to translate and know how to handle SDF files, then you have here the most recent information. HTH Marcus Ok, I realise this is still in migration but I'd like to raise this point right now. Overall, you rarely find people who are good at code who are also good translators and vice versa. Therefore relying on a localization setup that requires you to be able to read a Levelr 36 Scroll of Unix is a great way of keeping out people who are good at translation but bad at code. Like me. If one doesn't want end-users grumbling about shoddy translation, then one needs more good translators, which means not having obstacles like this. Cause I'm passing at what an SDF is... I'm sure that some lovely line of code that begins with $ but I don't know of it. I'm not in a hurry so I'll wait for Pootle to come online but at a philosophical level, the l10n side of AOO should bear that sort of thing in mind. Cheers Michael
[NL] Re: About the Former Native Language projects
Hi Ross, Thanks for the warm welcome :) 13/12/2011 08:39, sgrìobh Ross Gardler: Please tell us what you need in order to continue your work and where possible help us get it up and running. At this stage it is not clear what the best structure and process is, but you can help us find it. We ask for you patience, we need to ensure we create the best NL environment for everyone. For now that means time on this list, you've already seem that segregating activities on multiple lists can result in people being left behind. It can help with email management if you use, and encourage others to use, "[NL]" at the start of your subject lines. Note that, as a starting point our infrastructure team have setup a pootle server. Let's get you up and running on that server. Welcome to Apache OpenOffice. Well, I'm not sure I can speak for other locales, certainly not the big ones but I suspect many of the smaller locales (i.e. locales with very few team members will be in a similar position). Now, in an ideal world, I'd like to see the following: - AOO to be hosted on the same Pootle server as LibreOffice. With an arrangement for 3 separate "branches" - AOO/LO shared strings, AOO specific strings, LO specific strings. It would reduce the workload for small teams, which is a crucial factor. For teams with, say, a dozen or more active localizers it doesn't matters so much but if you're a 1-2 member team, having to manage yet another localization site, potentially with large overlaps, would result in serious capacity problems. Failing that, a really *easy* way of cross-porting the po files to absolutely minimize the workload for small teams. - A locale like Gaelic (I feel) doesn't need a full-blown locale site, we don't have critical mass on that scale. We currently redirect all stuff on the various localization projects to a general Gaelic forum with a special section on localization - and even that's quiet enough. I'd be perfectly happy with a small "corner" for downloads, some screenshots, basic info - the current solution over on LibreOffice (http://www.libreoffice.org/international-sites/) works very well for small teams, perhaps a days work to set it up and then very low maintenance. I'd be very happy with that. Whether that's a site like that, something more Wiki-esque or forum-like, I don't really mind. - Ideally, shared hosting of the extensions. Apologies if I'm treading on toes or if this has been debated before but Ross asked what my locale's needs are in terms of l10n ;) It's like this - I only have one extension, a Gaelic spellchecker. At the moment I'm hosting it on both extension sites and I'm forever trying to explain to people that they can use either... time, I could spend better cracking on with localizing something else. There may be technical reasons why that doesn't work but from an end-user and small locale point of view, having those two sites with extensions that work on either platform nonetheless is annoying. - As a matter of urgency, some simple download site where locales that got stuck when OO Pootle went down can get their po files. That's about it ;) If I'm upsetting politics, my apologies, as I said before, I have no interest in those when it comes to localization, the above is a totally neutral statement of what my locale's l10n needs would look like in an ideal world. Best Michael
Re: About the Former Native Language projects
Hi folks, I admit to mostly lurking but kinda feel compelled to chip in at this point. First off, I'm "just a translator", I came to OO late in the day to resucitate the Scottish Gaelic localization which had fallen format. I have no coding skills, at least none at the level needed to contribute code, so I consider my skills in translation my contribution. As such, I usually have little interest in the direction projects such as OO, Mozilla w/e take, code-wise or politically, except for trying to promote translator-friendly localization processes. The impending rift and eventual split took me completely by surprise. Literally. One day I had been translating away in Pootle, the next day it was dead and it took a lot of googling to eventually figure out what had been going on. I'm just glad I had taken a backup the day before, I don't know how many nascent projects have had their entire work frozen on Pootle since. Which is why I felt a little irked by the suggestion someone made that interested NL projects could "come forward". If it hadn't been for someone's blog post I came across eventually, I *still* wouldn't know that OO had "shifted" to Apache. I suspect very few NL projects will have come forward because for a long time it was not obvious to people not hooked into the develpment mailing lists (conjecture, mylord) that that's what happened. Apart from spam, nothing has ever been posted on the l10n list which was the only list I had subscribed to for the above reasons. So if "we're" supposed to step forward, perhaps someone should let the l10n list subscribers know? My main concern are the Gaelic users, however few those may be, who are still stuck on 3.01 and who know nothing of this break, apart from the fact that the extensions site has been going offline regulary. So I'd like to find some way of completing the localization - which should be relatively easy as I completed it over on LO, so they can finally update to whatever version is next. Salude e trigu, Michael And incidentally, translation *is* a technical skill - it just doesn't involve code dancing across the screen ;)
