[08:08] good morning all [08:43] hi [10:41] goood morning [10:41] dpm: got a minute? I've got a few questions about launchpad translation groups [10:42] hey TLE, sure [10:42] great [10:42] let me see if I've got this right [10:44] ~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] so, say the group ~lp-l10n-da is the danish subgroup of that [10:45] yeah, exactly [10:46] 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] BUT [10:46] we encourage not to create a translation group for each single project [10:46] 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] and rather use the launchpad-translators one [10:47] and then off course set the policy to structured or restricted [10:47] exactly [10:47] right [10:47] then my question [10:48] 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] even if it takes place, "circumventing" ~launchpad-translators? [10:49] the prokect in mind is scilab: https://launchpad.net/scilab [10:53] TLE, I don't think that's technically possible, but let me have a look at scilab first [10:54] what isn't? Assigning a group on a project-and-language basis or using the lp-l10n-da one? [10:58] 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] s from different groups [11:01] ok [11:01] 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] yeah [11:02] I've already joined theor localisation e-mail-list and I'll write them an email explaning the situation [11:04] 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] btw, scilab looks quite cool, is that an alternative to Matlab or Octave? [11:05] yea [11:05] awesome, we might look into translating it too, then :) [11:05] it looks like octave and scilab are competing as free software replacements for matlab [11:06] 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] so I wouldn't know which one to send your efforts after first, they both look pretty cool [11:08] yeah [11:08] at scilab they seem to have conversion tools for migration too, which is quite cool: http://www.scilab.org/news/events/20110322 [11:09] 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] and many developers don't know about the requirements for quality localisations [11:12] for the task I was doing yesterday, even between scilab and octave the are pretty close in syntax [11:12] 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] (though the comments of all things, are written in a different way, ) [11:13] dpm: that'd be great [11:15] 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] Launchpad bug 689700 in synapse-project "Suggestion for a translations permissions policy encouraging quality (affects: 1) (heat: 4)" [Low,Triaged] [11:25] afk for 10 min [11:27] and here's another example: https://answers.launchpad.net/geda/+question/123512 [11:47] dpm: thanks [11:49] ahhh, I think I finally getting all of this permission stuff [11:51] 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] dpm: right? [12:12] TLE, exactly [12:16] * TLE hears the penny drop [12:16] dpm: grea thanks [12:16] great [12:16] :) === hito_jp0 is now known as hito_jp