sajolida wrote (27 Mar 2015 22:55:00 GMT) : > Lunar:
>> sajolida:
>>>> SHOULD
>>>> ======
>>>> * provide support for Git branches (we could also agree upon translation
>>>> only master through this interface)
>>>
>>> What do you mean by "Git branches"?
>>
>> Imagine a branch where Claws Mail is replaced by Thunderbird. Changes
>> to the user documentation will happen in that branch. Ideally,
>> translators should be able to work from there so everyhing is ready when
>> the branch is merged. > Ok, then I added that as a MAY (topic branch) while standard branches
> (devel, stable, and testing) are SHOULD.
I'm a little bit concerned by the potential painful effects of
extending the granularity to topic branches:
* more merge conflicts to handle (and thus, what may seem as
increasing automation can in the end create more manual work);
* more chances that people start wasting their time translating stuff
that's simply not ready yet (draft documentation in topic
branches);
* more chances that people who are not very aware of how Git branches
work start translated stuff in the wrong place (e.g. improving the
Tor Browser doc's translation in the branch about the migration to
Thunderbird).
If the tools handle that just fine (e.g. by only presenting the new or
updated strings in topic branches), perfect. Otherwise, perhaps
translating stuff in devel (post-merge) or testing (post-freeze) is
good enough, and the benefits of allowing people to translate stuff
before it's deemed ready to be merged aren't worth the drawbacks.
In short: I'd keep devel/stable/testing in SHOULD, and would simply
drop the MAY about topic branches unless the tools handle this use
case very well.
