| dpm | good morning all | 08:08 |
|---|---|---|
| sagaci | hi | 08:43 |
| TLE | goood morning | 10:41 |
| TLE | dpm: got a minute? I've got a few questions about launchpad translation groups | 10:41 |
| dpm | hey TLE, sure | 10:42 |
| TLE | great | 10:42 |
| TLE | let me see if I've got this right | 10:42 |
| TLE | ~launchpad-translators is an "umbrella" group gathering a lot of subgroups for all the languages, and it is meant to be used by all the small/independent projects in launchpad | 10:44 |
| TLE | so, say the group ~lp-l10n-da is the danish subgroup of that | 10:44 |
| dpm | yeah, exactly | 10:45 |
| dpm | so in theory, each project can have their own translation group, and in fact a bunch of them have it already: https://translations.launchpad.net/+groups | 10:46 |
| dpm | BUT | 10:46 |
| dpm | we encourage not to create a translation group for each single project | 10:46 |
| TLE | if a projects decides they want quality over quantity they can assign the translations of their project to ~launchpad-translators and then the language subgroup will automatically be assigned to the translation into their language | 10:46 |
| dpm | and rather use the launchpad-translators one | 10:46 |
| TLE | and then off course set the policy to structured or restricted | 10:47 |
| dpm | exactly | 10:47 |
| TLE | right | 10:47 |
| TLE | then my question | 10:47 |
| TLE | if a project, for what ever reason, have decided not to use the ~launchpad-translators group, but encurage people to form a group for each language and are willing to assign the translation to that language (structured), can we then still use the ~lp-l10n-da for that | 10:48 |
| TLE | even if it takes place, "circumventing" ~launchpad-translators? | 10:49 |
| TLE | the prokect in mind is scilab: https://launchpad.net/scilab | 10:49 |
| dpm | TLE, I don't think that's technically possible, but let me have a look at scilab first | 10:53 |
| TLE | what isn't? Assigning a group on a project-and-language basis or using the lp-l10n-da one? | 10:54 |
| dpm | TLE, translation _teams_ are "attached" to translation _groups_. The project maintainers can only choose a translation group, not individual translation teams for each language. This greatly simplifies the set up, as the teams belonging to the group then get appointed for translation. So if a project maintainer chooses a particular translation group, only the teams in that group can translate the project. That is, in a project, you cannot mix team | 10:58 |
| dpm | s from different groups | 10:58 |
| TLE | ok | 11:01 |
| dpm | In this particular case, my recommendation would be to convince the scilab maintainers to use the launchpad-translators group. Looking at their translation settings, they don't make much sense, as they've chosen "Structured" without any translation group, which effectively makes their translations "Open" :( | 11:01 |
| TLE | yeah | 11:01 |
| TLE | I've already joined theor localisation e-mail-list and I'll write them an email explaning the situation | 11:02 |
| dpm | TLE, that'd be cool. I try to do this (convince project maintainers to use launchpad-translators or a translation group at all!) whenever I see a project with open permissions, but the message is much more powerful if translation teams ask for it themselves | 11:04 |
| dpm | btw, scilab looks quite cool, is that an alternative to Matlab or Octave? | 11:05 |
| TLE | yea | 11:05 |
| dpm | awesome, we might look into translating it too, then :) | 11:05 |
| TLE | it looks like octave and scilab are competing as free software replacements for matlab | 11:05 |
| TLE | I think octave is more feature completer (i.e. has more built in modules for wierd math stuff) but scilab has a "GUI builder" function, that people seems to miss when they cross over from matlab | 11:06 |
| TLE | so I wouldn't know which one to send your efforts after first, they both look pretty cool | 11:07 |
| dpm | yeah | 11:08 |
| dpm | at scilab they seem to have conversion tools for migration too, which is quite cool: http://www.scilab.org/news/events/20110322 | 11:08 |
| TLE | the problem with sending such e-mails (about having them assign a group) is that it is difficult to formulate so it doesn't get to sound like I know better what is best for them ;) | 11:09 |
| TLE | and many developers don't know about the requirements for quality localisations | 11:10 |
| TLE | for the task I was doing yesterday, even between scilab and octave the are pretty close in syntax | 11:12 |
| dpm | TLE, let me try to dig out a couple of bug reports I sent where I faced the same problem (i.e. trying to give guidance for translations without trying to be too pushy). Perhaps you can use them as a basis | 11:12 |
| TLE | (though the comments of all things, are written in a different way, ) | 11:13 |
| TLE | dpm: that'd be great | 11:13 |
| dpm | TLE, here's one, with a pretty simple explanation, let me see if I find one where I elaborated more on translation groups and stuff: https://bugs.launchpad.net/bugs/689700 | 11:15 |
| ubot4 | Launchpad bug 689700 in synapse-project "Suggestion for a translations permissions policy encouraging quality (affects: 1) (heat: 4)" [Low,Triaged] | 11:15 |
| TLE | afk for 10 min | 11:25 |
| dpm | and here's another example: https://answers.launchpad.net/geda/+question/123512 | 11:27 |
| TLE | dpm: thanks | 11:47 |
| TLE | ahhh, I think I finally getting all of this permission stuff | 11:49 |
| TLE | so when a gropu is assigned, the difference between structured and restricted is that if that group has a team or individual assigned to a language, he/they are the only ones that can approve translations fpr that language, but if there no one assigned to a lanuage within the group, the with structured it is open to anyone and with restricted it is closed to all | 11:51 |
| TLE | dpm: right? | 11:54 |
| dpm | TLE, exactly | 12:12 |
| * TLE hears the penny drop | 12:16 | |
| TLE | dpm: grea thanks | 12:16 |
| TLE | great | 12:16 |
| dpm | :) | 12:16 |
| === hito_jp0 is now known as hito_jp | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!