Re: DIS: Re: BUS: Either way you look at it... [also contains a CFJ ID number assignment]

[Kerim Aydin]

On Tue, 11 Jul 2017, Alex Smith wrote:
> On Tue, 2017-07-11 at 01:27 -0400, Owen Jacobson wrote:
> > I submit the following proposal:
> > 
> > Title: Caseload
> > AI: 2
> > {{{
> > 
> > Amend rule 991 (“Calls for Judgement”) and remove the sentence
> > 
> > The Arbitor SHALL assign judges over time such that all
> > interested players have reasonably equal opportunities to judge.
> > }}}
> > 
> > An Arbitor who unreasonably favours specific judges or denies
> > interested parties an opportunity to participate can be replaced in
> > multiple ways without resorting to Cards.
> 
> As an extra note, the sentence in question is causing some problems for
> me as it forces me to assign CFJs to players for which I'm not sure
> whether or not the player in question is still participating in Agora.

"Interested" is not explicitly defined.  I regularly dropped people who hadn't
shown "interest" in the game recently, or in judging on time (while announcing
  the fact).

Re: DIS: Re: BUS: Either way you look at it... [also contains a CFJ ID number assignment]

[Alex Smith]

On Thu, 2017-06-29 at 10:51 -0700, Kerim Aydin wrote:
> ais523 wrote:
> > Saying "A byte stream containing Arabic text must be interpreted as
> > though it were laid out left to right" would be in its own right
> > disrespectful to the language, because that's not how Arabic is written
> > in practice. 
> 
> So, the crux of it.  A couple thoughts.  I am a very rudimentary Arabic 
> speaker,
> learning from a couple books and reading street signs.  I've never typed it.
> I cut and paste it from Google translate.  Now, when I did the cut/paste, I
> wondered "would it paste into my editor in the opposite direction, or what?"
> 
> Imagine my surprise, when pasted, that, WHEN MY CURSOR WAS IN THE ARABIC TEXT,
> MY CONTROL KEYS WORKED BACKWARDS.  Backspace deleted to the right, and typing
> spaces and language-neutral punctuation moved the cursor right to left.  When
> I moved the cursor into the Latin text, it went back to what I was used to.  
> I thought "what wizardry is this??"  And I thought "these computer programmers
> (like you) who do these things are $%$%&$* brilliant!"  
> 
> But my other thought was, "hey, it just works".  It truly meant, that for an
> "Arabic writer", both the entry and the reading could naturally start from the
> right (then end in a gobbledigook reversed latin set of characters) just as 
> the
> English starts out correctly, then ends in reversed Arabic.  I don't know if
> this works for all email clients, but it was even preserved through emailing -
> I could reply to my Arabic message and get the same thing.  It's not perfect,
> e.g. line breaks, but for a single sentence on a single line - it just works,
> naturally, regardless of which language you thought you were typing.
> 
> So while I don't have any native Arabic speakers handy today, and line breaks
> are still a problem, I can look at that single line of text and think:  each
> part was entered/typed in the "correct" order for each language, as it truly
> was, and would be read that way by respective speakers of the languages.
> 
> So I wonder, as brilliant as the computer programming is that does this, is
> taking the programming view and breaking it down into the underlying bytes
> missing the forest for the trees?  You, or someone like you, created something
> that works for someone like me... why decompile?

Well, the point is that the text contains information about the full
order of all the text in it. If you press Home, you go to the logical
"start" of the line, regardless of whether that's in English or Arabic
(thus it might be the left or the right end). If you press End, you go
to the logical "end" of the line. In this particular line, the start is
in the English, and the end is in the Arabic; it could easily have been
written the other way round and look the same. This information isn't
preserved by accident, either; it's necessary to make the editing work
(i.e. where backspace deletes "back" whether that happens to be right
or left in this particular language), and it's needed to render the
text correctly. As a concrete example, the information is needed to
know whether the colon in the middle is after the English and before
the Arabic (in which case backspace when the cursor is near the colon
should delete it to the left), or whether it's before the English and
after the Arabic (in which case backspace when the cursor is near the
colon should delete it to the right). Each of these two cursor
behaviours gives a particular unambiguous meaning to the sentence in
question.

I admit to somewhat missing the forest for the trees in my judgement. I
(perhaps incorrectly) assumed that all this was common knowledge,
especially for people who used both Arabic and a left-to-right language
on computers, and looked at the bytes underlying the email to see what
they said about the logical order of the text they represented; it was
a fairly interesting legal point because the standards defining the
encoding in question are unclear, and thus I had to run through the
possibilities. I don't think I was as clear as I could have been about
why I was doing that, though.

-- 
ais523

Re: DIS: Re: BUS: Either way you look at it... [also contains a CFJ ID number assignment]

[Kerim Aydin]

天火狐 wrote:
> I do apologize that it has come to this. For what it's worth, I sympathize 
> with
> your point of view and I do think that your CFJ was brilliant, even if I 
> didn't
> exactly have time to submit a gratuitous argument to support you. 
> 天火狐
> (Apparently, that Japanese character guy)

I *think* I've learned to recognize your signature, and I've tried to associate
it with how google pronounces it - not quite a reflex yet though, and if there
were similar-looking characters I probably wouldn't notice the substitution :)

And I haven't minded your experiments - if nothing else, made me remember and
reflect on Douglas Hofstadter's chapter in Metamagical Themas on cross-language
fonts and font recognition, never a bad thing.


omd wrote:
> (btw, it's unfortunate that your CFJ database is now down :/).

That was a silly fit of pique.  And 3/4 is still your work, not mine!  It should
be up again now, let me know if not.


ais523 wrote:
> Saying "A byte stream containing Arabic text must be interpreted as
> though it were laid out left to right" would be in its own right
> disrespectful to the language, because that's not how Arabic is written
> in practice. 

So, the crux of it.  A couple thoughts.  I am a very rudimentary Arabic speaker,
learning from a couple books and reading street signs.  I've never typed it.
I cut and paste it from Google translate.  Now, when I did the cut/paste, I
wondered "would it paste into my editor in the opposite direction, or what?"

Imagine my surprise, when pasted, that, WHEN MY CURSOR WAS IN THE ARABIC TEXT,
MY CONTROL KEYS WORKED BACKWARDS.  Backspace deleted to the right, and typing
spaces and language-neutral punctuation moved the cursor right to left.  When
I moved the cursor into the Latin text, it went back to what I was used to.  
I thought "what wizardry is this??"  And I thought "these computer programmers
(like you) who do these things are $%$%&$* brilliant!"  

But my other thought was, "hey, it just works".  It truly meant, that for an
"Arabic writer", both the entry and the reading could naturally start from the
right (then end in a gobbledigook reversed latin set of characters) just as the
English starts out correctly, then ends in reversed Arabic.  I don't know if
this works for all email clients, but it was even preserved through emailing -
I could reply to my Arabic message and get the same thing.  It's not perfect,
e.g. line breaks, but for a single sentence on a single line - it just works,
naturally, regardless of which language you thought you were typing.

So while I don't have any native Arabic speakers handy today, and line breaks
are still a problem, I can look at that single line of text and think:  each
part was entered/typed in the "correct" order for each language, as it truly
was, and would be read that way by respective speakers of the languages.

So I wonder, as brilliant as the computer programming is that does this, is
taking the programming view and breaking it down into the underlying bytes
missing the forest for the trees?  You, or someone like you, created something
that works for someone like me... why decompile?

Re: DIS: Re: BUS: Either way you look at it... [also contains a CFJ ID number assignment]

[Alex Smith]

On Thu, 2017-06-29 at 09:14 -0700, Publius Scribonius Scholasticus
wrote:
> My issue is where in the course of his judgement, he stated that a
> CFJ existed then immediately assigned it.

I'd already attempted to assign it to myself earlier (if it existed),
so that was just reducing ambiguity.

The CFJ itself also wasn't an attempt to resolve any sort of
controversy; rather, it was a situation in which it had been created
ambiguously, and the controversy was as to whether it existed at all,
not about what the judgement should be. So it really didn't matter who
judged it.

-- 
ais523

Re: DIS: Re: BUS: Either way you look at it... [also contains a CFJ ID number assignment]

[Publius Scribonius Scholasticus]

Yes, but I believe it violated Rule 991 and consisted of an abuse of official 
office.

Publius Scribonius Scholasticus
p.scribonius.scholasti...@gmail.com



> On Jun 29, 2017, at 9:15 AM, Quazie  wrote:
> 
> But he had already assigned it if it existed on official - he just gave it a 
> number while issuing judgements
> 
> On Thu, Jun 29, 2017 at 09:14 Publius Scribonius Scholasticus 
>  wrote:
> My issue is where in the course of his judgement, he stated that a CFJ 
> existed then immediately assigned it.
> 
> Publius Scribonius Scholasticus
> p.scribonius.scholasti...@gmail.com
> 
> 
> 
> > On Jun 29, 2017, at 9:13 AM, Quazie  wrote:
> >
> > Also: prior rules and game custom allow for linking of CFJs that are 
> > related - why haven't you been upset at other instances where multiple CFJs 
> > were assigned at once?
> >
> > On Thu, Jun 29, 2017 at 09:10 Publius Scribonius Scholasticus 
> >  wrote:
> > 1 - Really? Okay then, I point my finger at ais523 for the reasons stated 
> > before.
> >
> > 2 - Game flow is not a consideration that the rules allow for.
> >
> > 3 - That is completely irrelevant it requires support not lack of objection.
> > 
> > Publius Scribonius Scholasticus
> > p.scribonius.scholasti...@gmail.com
> >
> >
> >
> > > On Jun 29, 2017, at 9:05 AM, Quazie  wrote:
> > >
> > > 1 - you can't assign pink slips - only the Referee can
> > > 2 - I disagree with your conjecture - those CFJ assignments were 
> > > reasonable and made the game flow better
> > > 3 - I object to your moot intent
> > >
> > > On Thu, Jun 29, 2017 at 08:58 Publius Scribonius Scholasticus 
> > >  wrote:
> > > I hereby intend to render judgement 3534 moot.
> > >
> > > I issue a Pink Slip to ais523 for abuse of his office as Arbiter. He had 
> > > unduly assigned CFJs to himself in an inequitable manner, which has not 
> > > assigned judgements in such a way that "interested players have 
> > > reasonably equal opportunities to judge.”, as required by Rule 991.
> > > 
> > > Publius Scribonius Scholasticus
> > > p.scribonius.scholasti...@gmail.com
> > >
> > >
> > >
> > > > On Jun 29, 2017, at 3:57 AM, Alex Smith  
> > > > wrote:
> > > >
> > > > Judge's evidence on CFJs 3534/3535:
> > > > {{{
> > > > On Wed, 2017-06-28 at 16:16 -0700, Kerim Aydin wrote:
> > > >> I call for judgement on the following statement : أدعو إلى إصدار حكم 
> > > >> بشأن البيان التالي
> > > >
> > > > The source of the body for the above-quoted message is (with bytes
> > > > outside the ASCII range replaced by hexadecimal numbers in angle
> > > > brackets):
> > > >
> > > >>   This message is in MIME format.  The first part should be readable 
> > > >> text,
> > > >>   while the remaining parts are likely unreadable without MIME-aware 
> > > >> tools.
> > > >>
> > > >> ---1903399159-33069213-1498691760=:22422
> > > >> Content-Type: TEXT/PLAIN; charset=ISO-8859-6
> > > >> Content-Transfer-Encoding: 8bit
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> I call for judgement on the following statement :  
> > > >> 
> > > >>  
> > > >>
> > > >>
> > > >>
> > > >> ---1903399159-33069213-1498691760=:22422--
> > > > }}}
> > > >
> > > > Judge's arguments on CFJs 3534/3535:
> > > > {{{
> > > > The arguments so far have hinged on the message in question being
> > > > ambiguous, but is that really the case? I believe that, given the
> > > > method via which it was sent, the original message cannot reasonably be
> > > > interpreted as being in Arabic.
> > > >
> > > > What's notable here is that an encoding of text can convey the meaning
> > > > of the text in two different ways; either using a visual ordering, in
> > > > which the sequence of bytes is corresponds to the positions of the
> > > > individual characters on the page; or a logical ordering, in which the
> > > > sequence of bytes corresponds to the order in which the characters they
> > > > represent have meaning (i.e. bytes that appear earlier in the byte
> > > > stream correspond to letters closer to the start of words, words closer
> > > > to the start of sentences, and so on). A visual ordering would not help
> > > > resolve the ambiguity in respect to the CFJ. A logical ordering would,
> > > > though, as the bytes are conveying not only the appearance of the text
> > > > in this case, but also the intended reading order.
> > > >
> > > > The standard referenced in the message for the understanding of the
> > > > bytes it contains is ISO-8859-6 (which cannot be obtained from ISO
> > > > without payment, but Ecma have a standard Ecma-114 which they claim is
> > > > equivalent). The body of the standard contains no opinion on whether
> > > > the text it's used to represent is in logical or visual order. However,
> > > > email clients in practice appear to interpret it 

Re: DIS: Re: BUS: Either way you look at it... [also contains a CFJ ID number assignment]

[Quazie]

But he had already assigned it if it existed on official - he just gave it
a number while issuing judgements

On Thu, Jun 29, 2017 at 09:14 Publius Scribonius Scholasticus <
p.scribonius.scholasti...@googlemail.com> wrote:

> My issue is where in the course of his judgement, he stated that a CFJ
> existed then immediately assigned it.
> 
> Publius Scribonius Scholasticus
> p.scribonius.scholasti...@gmail.com
>
>
>
> > On Jun 29, 2017, at 9:13 AM, Quazie  wrote:
> >
> > Also: prior rules and game custom allow for linking of CFJs that are
> related - why haven't you been upset at other instances where multiple CFJs
> were assigned at once?
> >
> > On Thu, Jun 29, 2017 at 09:10 Publius Scribonius Scholasticus <
> p.scribonius.scholasti...@googlemail.com> wrote:
> > 1 - Really? Okay then, I point my finger at ais523 for the reasons
> stated before.
> >
> > 2 - Game flow is not a consideration that the rules allow for.
> >
> > 3 - That is completely irrelevant it requires support not lack of
> objection.
> > 
> > Publius Scribonius Scholasticus
> > p.scribonius.scholasti...@gmail.com
> >
> >
> >
> > > On Jun 29, 2017, at 9:05 AM, Quazie  wrote:
> > >
> > > 1 - you can't assign pink slips - only the Referee can
> > > 2 - I disagree with your conjecture - those CFJ assignments were
> reasonable and made the game flow better
> > > 3 - I object to your moot intent
> > >
> > > On Thu, Jun 29, 2017 at 08:58 Publius Scribonius Scholasticus <
> p.scribonius.scholasti...@googlemail.com> wrote:
> > > I hereby intend to render judgement 3534 moot.
> > >
> > > I issue a Pink Slip to ais523 for abuse of his office as Arbiter. He
> had unduly assigned CFJs to himself in an inequitable manner, which has not
> assigned judgements in such a way that "interested players have reasonably
> equal opportunities to judge.”, as required by Rule 991.
> > > 
> > > Publius Scribonius Scholasticus
> > > p.scribonius.scholasti...@gmail.com
> > >
> > >
> > >
> > > > On Jun 29, 2017, at 3:57 AM, Alex Smith 
> wrote:
> > > >
> > > > Judge's evidence on CFJs 3534/3535:
> > > > {{{
> > > > On Wed, 2017-06-28 at 16:16 -0700, Kerim Aydin wrote:
> > > >> I call for judgement on the following statement : أدعو إلى إصدار
> حكم بشأن البيان التالي
> > > >
> > > > The source of the body for the above-quoted message is (with bytes
> > > > outside the ASCII range replaced by hexadecimal numbers in angle
> > > > brackets):
> > > >
> > > >>   This message is in MIME format.  The first part should be
> readable text,
> > > >>   while the remaining parts are likely unreadable without
> MIME-aware tools.
> > > >>
> > > >> ---1903399159-33069213-1498691760=:22422
> > > >> Content-Type: TEXT/PLAIN; charset=ISO-8859-6
> > > >> Content-Transfer-Encoding: 8bit
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> I call for judgement on the following statement : 
>
>  
> > > >>
> > > >>
> > > >>
> > > >> ---1903399159-33069213-1498691760=:22422--
> > > > }}}
> > > >
> > > > Judge's arguments on CFJs 3534/3535:
> > > > {{{
> > > > The arguments so far have hinged on the message in question being
> > > > ambiguous, but is that really the case? I believe that, given the
> > > > method via which it was sent, the original message cannot reasonably
> be
> > > > interpreted as being in Arabic.
> > > >
> > > > What's notable here is that an encoding of text can convey the
> meaning
> > > > of the text in two different ways; either using a visual ordering, in
> > > > which the sequence of bytes is corresponds to the positions of the
> > > > individual characters on the page; or a logical ordering, in which
> the
> > > > sequence of bytes corresponds to the order in which the characters
> they
> > > > represent have meaning (i.e. bytes that appear earlier in the byte
> > > > stream correspond to letters closer to the start of words, words
> closer
> > > > to the start of sentences, and so on). A visual ordering would not
> help
> > > > resolve the ambiguity in respect to the CFJ. A logical ordering
> would,
> > > > though, as the bytes are conveying not only the appearance of the
> text
> > > > in this case, but also the intended reading order.
> > > >
> > > > The standard referenced in the message for the understanding of the
> > > > bytes it contains is ISO-8859-6 (which cannot be obtained from ISO
> > > > without payment, but Ecma have a standard Ecma-114 which they claim
> is
> > > > equivalent). The body of the standard contains no opinion on whether
> > > > the text it's used to represent is in logical or visual order.
> However,
> > > > email clients in practice appear to interpret it as being in logical
> > > > order; in my client, the bytes , corresponding to the
> > > > Arabic letters «أ» then «د» then «ع» then «و», are rendered as the
> > > > Arabic word «أدعو» (in other words, they're rendered right to left,
> the
> > > > normal logical order of Arabic, and the opposite order that 

Re: DIS: Re: BUS: Either way you look at it... [also contains a CFJ ID number assignment]

[Publius Scribonius Scholasticus]

My issue is where in the course of his judgement, he stated that a CFJ existed 
then immediately assigned it.

Publius Scribonius Scholasticus
p.scribonius.scholasti...@gmail.com



> On Jun 29, 2017, at 9:13 AM, Quazie  wrote:
> 
> Also: prior rules and game custom allow for linking of CFJs that are related 
> - why haven't you been upset at other instances where multiple CFJs were 
> assigned at once?
> 
> On Thu, Jun 29, 2017 at 09:10 Publius Scribonius Scholasticus 
>  wrote:
> 1 - Really? Okay then, I point my finger at ais523 for the reasons stated 
> before.
> 
> 2 - Game flow is not a consideration that the rules allow for.
> 
> 3 - That is completely irrelevant it requires support not lack of objection.
> 
> Publius Scribonius Scholasticus
> p.scribonius.scholasti...@gmail.com
> 
> 
> 
> > On Jun 29, 2017, at 9:05 AM, Quazie  wrote:
> >
> > 1 - you can't assign pink slips - only the Referee can
> > 2 - I disagree with your conjecture - those CFJ assignments were reasonable 
> > and made the game flow better
> > 3 - I object to your moot intent
> >
> > On Thu, Jun 29, 2017 at 08:58 Publius Scribonius Scholasticus 
> >  wrote:
> > I hereby intend to render judgement 3534 moot.
> >
> > I issue a Pink Slip to ais523 for abuse of his office as Arbiter. He had 
> > unduly assigned CFJs to himself in an inequitable manner, which has not 
> > assigned judgements in such a way that "interested players have reasonably 
> > equal opportunities to judge.”, as required by Rule 991.
> > 
> > Publius Scribonius Scholasticus
> > p.scribonius.scholasti...@gmail.com
> >
> >
> >
> > > On Jun 29, 2017, at 3:57 AM, Alex Smith  wrote:
> > >
> > > Judge's evidence on CFJs 3534/3535:
> > > {{{
> > > On Wed, 2017-06-28 at 16:16 -0700, Kerim Aydin wrote:
> > >> I call for judgement on the following statement : أدعو إلى إصدار حكم 
> > >> بشأن البيان التالي
> > >
> > > The source of the body for the above-quoted message is (with bytes
> > > outside the ASCII range replaced by hexadecimal numbers in angle
> > > brackets):
> > >
> > >>   This message is in MIME format.  The first part should be readable 
> > >> text,
> > >>   while the remaining parts are likely unreadable without MIME-aware 
> > >> tools.
> > >>
> > >> ---1903399159-33069213-1498691760=:22422
> > >> Content-Type: TEXT/PLAIN; charset=ISO-8859-6
> > >> Content-Transfer-Encoding: 8bit
> > >>
> > >>
> > >>
> > >>
> > >> I call for judgement on the following statement :  
> > >> 
> > >>  
> > >>
> > >>
> > >>
> > >> ---1903399159-33069213-1498691760=:22422--
> > > }}}
> > >
> > > Judge's arguments on CFJs 3534/3535:
> > > {{{
> > > The arguments so far have hinged on the message in question being
> > > ambiguous, but is that really the case? I believe that, given the
> > > method via which it was sent, the original message cannot reasonably be
> > > interpreted as being in Arabic.
> > >
> > > What's notable here is that an encoding of text can convey the meaning
> > > of the text in two different ways; either using a visual ordering, in
> > > which the sequence of bytes is corresponds to the positions of the
> > > individual characters on the page; or a logical ordering, in which the
> > > sequence of bytes corresponds to the order in which the characters they
> > > represent have meaning (i.e. bytes that appear earlier in the byte
> > > stream correspond to letters closer to the start of words, words closer
> > > to the start of sentences, and so on). A visual ordering would not help
> > > resolve the ambiguity in respect to the CFJ. A logical ordering would,
> > > though, as the bytes are conveying not only the appearance of the text
> > > in this case, but also the intended reading order.
> > >
> > > The standard referenced in the message for the understanding of the
> > > bytes it contains is ISO-8859-6 (which cannot be obtained from ISO
> > > without payment, but Ecma have a standard Ecma-114 which they claim is
> > > equivalent). The body of the standard contains no opinion on whether
> > > the text it's used to represent is in logical or visual order. However,
> > > email clients in practice appear to interpret it as being in logical
> > > order; in my client, the bytes , corresponding to the
> > > Arabic letters «أ» then «د» then «ع» then «و», are rendered as the
> > > Arabic word «أدعو» (in other words, they're rendered right to left, the
> > > normal logical order of Arabic, and the opposite order that they appear
> > > in the bytestream).
> > >
> > > The word in question is a real Arabic word, translating to "I invite" /
> > > "I call" / "I appeal". If we reverse the order of the letters, to get
> > > «دعوأ», this is no longer a real Arabic word, strongly implying that
> > > the message was meant to be in logical order; if the message were meant
> > > to be in visual order, the 

Re: DIS: Re: BUS: Either way you look at it... [also contains a CFJ ID number assignment]

[Josh T]

I'm going to be honest, I am pretty surprised that you all let me get away
with most of what I've done in Japanese.

天火狐

On 29 June 2017 at 12:07, omd  wrote:

> On Thu, Jun 29, 2017 at 4:09 PM, Kerim Aydin 
> wrote:
> > I register.
> >
> > H. Registrar, the following is a Cantus Cygneus:
>
> Oof :/
>
> > Fine, it's just a nickname.  Then, I argued against interpretation of
> > contracts in other languages.  Ignored.  I gave in a bit, thinking
> > "hey, maybe changing technology means this should be re-evaluated",
> > and delivered judgements allowing some minimal use of characters for
> > obvious simple actions.  This though went further for the rest of you,
> > not only do you bend over backwards to interpret long and nonsensical
> > Japanese posts, but now you try to interpret goddamn Neo Akkadian with
> > seriousness.
>
> For the record, I 'bent over backwards' to interpret the long Japanese
> post because I'm learning Japanese, therefore it was a fun exercise.
> Not because I thought any announcements in it would be legally
> effective; I don't think there's any reason to overturn CFJ 1460 (btw,
> it's unfortunate that your CFJ database is now down :/).
>

Re: DIS: Re: BUS: Either way you look at it... [also contains a CFJ ID number assignment]

[Alex Smith]

On Thu, 2017-06-29 at 11:26 -0400, Josh T wrote:
> While I am not a programmer that has needed to deal with
> internationalization, it is to my understanding from friends in the field
> that most implementations get it wrong, and thus how any one program
> renders it should not be taken as evidence one way or another. For example,
> I don't know for certain if the text viewers of each right honourable
> Agoran supports the correct CJK flags that forces the font to render the
> correct Unihan variant. While I am not familiar with Arabic encoding (I
> don't speak Arabic, although if I tried really hard maybe I can use my
> knowledge of Akkadian to decipher text?), it is my understanding that
> Unicode encodes text by order of input and not "logically" as a concession
> for backwards compatibility, and thus feel that stating that the text
> should be interpreted as English because it is left-aligned is like having
> a chef that doesn't know how to prepare lobster but tries his best anyway,
> but eir customers conclude that lobster isn't good because of
> unintentionally ill-suited decisions the chef made.

Right, that's why I had to look into the actual byte stream of the
message. The encoding listed in the email (which is not a Unicode
encoding) is normally logical, but can be physical (it's somewhat
underspecified). However, if it's interpreted as physical, the Arabic
is written backwards (and thus meaningless). As such, the only sensible
conclusion is that the text is actually written in logical order, which
would imply that the English comes first. (It could also have been
written with the Arabic first to produce the same visual appearance,
but it wasn't.)

-- 
ais523

Re: DIS: Re: BUS: Either way you look at it... [also contains a CFJ ID number assignment]

[Josh T]

While I am not a programmer that has needed to deal with
internationalization, it is to my understanding from friends in the field
that most implementations get it wrong, and thus how any one program
renders it should not be taken as evidence one way or another. For example,
I don't know for certain if the text viewers of each right honourable
Agoran supports the correct CJK flags that forces the font to render the
correct Unihan variant. While I am not familiar with Arabic encoding (I
don't speak Arabic, although if I tried really hard maybe I can use my
knowledge of Akkadian to decipher text?), it is my understanding that
Unicode encodes text by order of input and not "logically" as a concession
for backwards compatibility, and thus feel that stating that the text
should be interpreted as English because it is left-aligned is like having
a chef that doesn't know how to prepare lobster but tries his best anyway,
but eir customers conclude that lobster isn't good because of
unintentionally ill-suited decisions the chef made.

天火狐

On 29 June 2017 at 10:55, Alex Smith  wrote:

> On Thu, 2017-06-29 at 07:09 -0700, Kerim Aydin wrote:
> > But hey - this Arabic stuff??  Well, it's not some important language,
> > like say Japanese.  Let's just translate it to bytes and ignore the
> > meaning, eh?  Completely re-arrange the word order like no native
> > speaker, and not even a translation machine, would do, eh?  I guess
> > that's fine.  Basic principles of reading with good faith don't apply
> > to a language like *that*.  Let's talk about byte order, instead.
>
> Sorry for harping on about this, I'm just really annoyed myself at what
> you've written.
>
> It feels like all the effort I've gone to to do things like understand
> and work with languages like Arabic have been wasted. A lot of people
> have put in a lot of effort in order to create communication standards
> that allow text in all languages, not just English, to be understood
> unambiguously when communicated from one person to another. And now I'm
> finding out that that all that work is irrelevant, because when people
> actually write in Arabic, I'm expected to ignore what what they say
> actually means, and assume that I should take the primitive
> understanding that it's all just left-to-right, left-margin-justified
> text?
>
> Arabic has its own rules for writing it, whether on paper or on
> computer. (The very simplest is that, whether on paper or computer, you
> start at the right hand side of the page.) If you don't follow those
> rules, it shouldn't be surprising that the meaning that people ascribe
> to the message you send isn't the same as the one you intended. In
> particular, following the same rules as for English is going to produce
> a result that's meaningless in Arabic; text's going to wrap in the
> wrong places, embedded quotations in left-to-right languages will be in
> the wrong places, and so on. It can, however, sometimes produce a
> result that's meaningful in English, especially when there's English
> text in the same sentence.
>
> (To be honest, I was expecting that you'd follow up your CFJ by
> submitting the same thing as an image, which can't be reflowed or
> parsed and which is therefore missing the context you'd need to be able
> to unambiguously determine the direction it was written in. I was
> surprised by the apparent lack of understanding of encoding standards
> for writing various different languages. Perhaps this is the fault of
> computer software generally still being rather English-centric, and
> making entering text in other languages more error-prone than it should
> be; I know I've seen my email client produce incorrect or suboptimal
> results both with your Arabic, and with 天火狐's Japanese. This is
> something I'm working on at the moment – I'm trying to write a
> rendering library which handles all these languages correctly.)
>
> --
> ais523
>