Hi,
> Fixed.
Thanks for the many fixes.
>>> What's the Tails requirement for multi language support?
>>
>> I'm not sure what you mean. In any case, "3.3 Internationalization" in
>> our design doc might help.
> I am still not sure. Maybe I put a bit to much into "The TBB ships
> l10n'd packages, while Tails needs to support as many languages as
> possible." [1]
For the record, the TBB splitting per-language packages was merely one
of the *integration* issues that prevented us from using the TBB.
> The question boils down to, when creating new features that require user
> interaction or have user output, does it have have to provide
> internationalization support to support as many languages as possible?
Yes, we do insist on all Tails -specific software being i18n'd: see
"2.6.4.1 Internationalization" in the PELD spec. I believe we are
generally doing pretty well on this side, despite some serious
glitches (e.g. suboptimal tails-greeter behavior for RTL languages).
To further clarify, we're insisting *on i18n only* during initial
development: actual l10n work (translation etc.) can be done later, so
that's not seriously delaying things (one would not seriously think of
writing production-ready end-user interfaces that are not i18n'd
anyway; this is 2013).
Therefore, "Whonix does not (yet) have the requirement to support as
many languages as possible before a feature can be added", suggesting
it may be different in Tails, sounds quite misleading to me: it sounds
like lack of i18n might be a feature Whonix has, and Tails might not
have...
> I agree. "Obey" is the wrong way to put it. You're not telling anyone
> what to work on. And even have a decision making process. That's really
> not what I wanted to say.
Heard.
> "As a code contributor to Tails, adrelanos would have to accept
> decisions made by the Tails decision making process and couldn't simply
> modify anything as personally desired, preferred or believed to be the
> best solution."
Thanks for fixing this, and above all thanks for being honest about
your personal expectations.
I find these expectations scary for the Whonix project (and for Whonix
users), as it seems to imply that you'll have to forever remain the
final decision maker in there (benevolent dictator for life, as they
say). But well, that's obviously your call.
>> c. By affirming that strongly that one has to "obey" else
>> "contributions do not get merged", it suggests that there are
>> precedents of this process. Reference needed.
> The word "obey" has already been corrected.
> The reason for pointing the quoted sentence above is to answer "Why
> Whonix, why not contribute to Tails instead?" like questions.
> Example, I like to see XChat in Tails:
> https://mailman.boum.org/pipermail/tails-dev/2012-August/001442.html
> Decision making process says no.
Just to clarify, my understanding of what happened is quite different.
First, the only reason you provided in this thread, in support for
shipping XChat, was sharing anonymity set with Whonix. It's obviously
not a sufficient one.
Second, decision making process was stalled at "Unless we have a very
strong argument that proves us that XChat does things that Pidgin do
not and that most of Tails users would benefit of". As far as I can
tell, I've seen no such argument being made, so the decision making
process has been stalled since then (and status quo remains until some
progress is made).
So, the change you "recommended" was not made.
To be honest, I've rarely seen free software projects do important
change merely because they were "recommended" by someone who:
1. is not providing any half-convincing reason to back the change
2. is not volunteering to do the work involved by the proposal
3. hasn't the background that makes a mere "recommendation" of
theirs be enough for us to go guess the rationale ourselves (you
know, even Jake gets turned down most of the time when he dares
recommending changes to us without bothering / having time to
attach some convincing rationale ;)
> I can do nothing but accept it.
I beg to disagree: you're welcome to participate further in the
decision making process, e.g. by explaining why, according to you,
this change should be made.
But yeah, it's entirely possible that the decision that is made in the
end does not suit you perfectly. Even with consensus-driven decision
making, it happens, and not only to you: even I, with my quite central
position in the Tails decision making process, could probably list
a few design or implementation decisions I'm not very happy with, but
can live with.
> Now, when I dislike the decision and I strongly care about it, I can do
> nothing other than either fork Tails or start a new project.
... or realize that, with persistence + remembered additional
packages, XChat lovers can get their preferred stuff easily every time
they boot Tails, so perhaps it's no big deal eventually?
I very probably missed why you care that much about XChat, so I'm
sorry I call this a "minor reason", but from my PoV, it seems uncommon
for free software project to fork (or for rock bands to split) for
this kind of relatively minor reasons. I mean, if people routinely
behaved this way, we would have a few dozens diverging forks of the
Linux kernel.
This being said, I do warmly welcome forks of Tails, especially if
they're not diverging ones (that is, if we can share work and
results).
> Problem is, I don't know any wiki host interested in this kind of topic,
> where (registered) Tor users are free to edit, and where the involved
> projects are willing to participate. If there was, I am sure the
> involved projects all are mature enough to make it objectively correct
> in no time.
Personally, I'm not interested in working on this comparison (yet),
so I don't care where it is hosted and who can edit it.
> The faq entry is supposed to be a subjective answer, why I maintain a
> separate project, which differences I personally care about.
I suggest making this clear on that page, then.
> The comparison page is supposed to be as objective/factual
> as possible.
Then perhaps it should not use the "Why don't you merge with Tails and
join efforts?" FAQ as a reference (in "Many other differences"
section), 'cause doing this makes at least me read that FAQ with the
same expectations.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
