[08:08] <dpm> good morning all
[08:43] <sagaci> hi
[10:41] <TLE> goood morning
[10:41] <TLE> dpm: got a minute? I've got a few questions about launchpad translation groups
[10:42] <dpm> hey TLE, sure
[10:42] <TLE> great
[10:42] <TLE> let me see if I've got this right
[10:44] <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:45] <dpm> yeah, exactly
[10:46] <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:47] <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:48] <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:49] <TLE> even if it takes place, "circumventing" ~launchpad-translators?
[10:49] <TLE> the prokect in mind is scilab: https://launchpad.net/scilab
[10:53] <dpm> TLE, I don't think that's technically possible, but let me have a look at scilab first
[10:54] <TLE> what isn't? Assigning a group on a project-and-language basis or using the lp-l10n-da one?
[10:58] <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
[11:01] <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:02] <TLE> I've already joined theor localisation e-mail-list and I'll write them an email explaning the situation
[11:04] <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:05] <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:06] <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:07] <TLE> so I wouldn't know which one to send your efforts after first, they both look pretty cool
[11:08] <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:09] <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:10] <TLE> and many developers don't know about the requirements for quality localisations
[11:12] <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:13] <TLE> (though the comments of all things, are written in a different way, )
[11:13] <TLE> dpm: that'd be great
[11:15] <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:25] <TLE> afk for 10 min
[11:27] <dpm> and here's another example: https://answers.launchpad.net/geda/+question/123512
[11:47] <TLE> dpm: thanks
[11:49] <TLE> ahhh, I think I finally getting all of this permission stuff
[11:51] <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:54] <TLE> dpm: right?
[12:12] <dpm> TLE, exactly
[12:16]  * TLE hears the penny drop
[12:16] <TLE> dpm: grea thanks
[12:16] <TLE> great
[12:16] <dpm> :)