W3C home > Mailing lists > Public > public-secondscreen@w3.org > November 2015

Re: [presentation-api] Possibility for a character to be interpreted differently depending on locale

From: r12a via GitHub <sysbot+gh@w3.org>
Date: Thu, 12 Nov 2015 17:18:12 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-156171699-1447348691-sysbot+gh@w3.org>
ok, I'll try to summarise what we just discussed in the i18n telecon. 

the issue here is that some ideographic characters may look foreign to
 the reader unless a language-sensitive font is applied.  (btw, this 
can be the case for other scripts too, including arabic and latin)

we are only talking about minor differences between characters, and 
they are more likely to affect readability rather than meaning.  When 
significant differences arise, such as for 门  and 門, which have a 
different number of strokes, then Unicode uses separate code points, 
including (as for that example) to reflect the differences between 
Simplified and Traditional forms of the same character.   
Nevertheless, it *is* a real issue, and it is important that it be 
addressed.  

there needs to be some information associated with the content in 
question that describes what language it is in.  If information is 
taken, say, from an HTML page, the `lang` attribute should provide 
that information.

in order for the appropriate font to be applied by the receiver at 
display time, it will be necessary to pass information with JSON 
strings to indicate the language of the content.  There needs to be a 
mechanism to allow this.  It should use BCP47 language tags.

on the receiving end, the application that handles the display of the 
strings needs to be able to associate a language-appropriate font with
 the string so that Chinese text uses Chinese font forms, and Japanese
 text uses Japanese font forms, etc.  All the major desktop browsers 
already do that (fwiw see the test results at 
http://www.w3.org/International/tests/repo/results/default-font – 
click on the text in the 'Test link' column to try the test).

HTTP's accept-language addresses a different problem (language 
negotiation), and so is not likely to be useful here. Basically, it is
 used to request a specific language variant – eg. i want the content 
in Chinese or in Japanese, etc.  If the content is available in that 
language, it can be sent to the receiver, but the problem of choosing 
the correct font for display still requires a knowledge of which 
language the content is in (which is the problem we are concerned 
with).

does that help?


-- 
GitHub Notif of comment by r12a
See 
https://github.com/w3c/presentation-api/issues/218#issuecomment-156171699
Received on Thursday, 12 November 2015 17:18:14 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 12 November 2015 17:18:15 UTC