intrigeri:
> 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.
I do not have a strong opinion on this and thus agree with your proposal.
Cheers
u.
