W3C home > Mailing lists > Public > www-international@w3.org > July to September 2010

Re: some info related to internationalization in EPUB

From: Felix Sasaki <felix.sasaki@fh-potsdam.de>
Date: Wed, 29 Sep 2010 22:07:14 +0200
Message-ID: <AANLkTin+M1Y_fTRPPDPosxfFFvdZufQTQngB4YCH1MZB@mail.gmail.com>
To: "KangHao Lu (Kenny)" <kennyluck@w3.org>
Cc: WWW International <www-international@w3.org>, ITS Interest Group <public-i18n-its-ig@w3.org>, "MURATA (FAMILY Given)" <eb2m-mrt@asahi-net.or.jp>, Brady Duga <duga@ebooktechnologies.com>
Hello Kenny,

many thanks for this information. Some personal comments below.

2010/9/29 KangHao Lu (Kenny) <kennyluck@w3.org>

> Hi internationalization folks,
>
> This is some background info concerning the possible collaboration between
> the internationalization activity and IDPF's EPUB e-book format. This is
> brought up in the internationalization
>
> Murata-san, the chair of EGLS (Enhanced Global Language Support subgroup),
> has compiled the list of requirements [1], and the goal for the Taipei
> meeting next week (Oct. 5, 6) is to identify potential solutions. Since the
> participants of EGLS mostly consists of east Asian people, I do worry that
> some other internationalization requirements besides CJK-issues are not
> covered.
>
> The following requirements raised by the participants (see the latter part
> of [1]) are not covered in the compiled version (the former part of [1]):
>
> - EGLS_JT_1 Hebrew character support
>
> I personally think this is a font issue, and it should be almost covered by
> EGLS_CG4 - Font Embedding
>
> - EGLS_JT_2 Bi-directional text
>
> I personally think this is already covered by EPUB 2.0.
>
> - EGLS_JT_3 Diacritical mark placement
>
> This I have no idea.
>
> - EGLS_PS_R1Use UAX#14 (Unicode Line Breaking Algorithm)
>
> This seems to be like an anti-requirement of the EGLS_LBR series. FYI, CSS3
> Text Level 3 will probably have the 'line-break' property which will violate
> pure UAX#14.
>
>
> As IDPF has a very tight schedule, the deadline for new requirements
> already past. I don't know whether it is still possible to bring up new
> requirements related to internationalization, but if you have new
> requirement, I can bring it to the Taipei meeting next week to see if
> exceptions can be made. I personally think IDPF is very
> internationalization-friendly.
>
> EGLS might have a IRC conference meeting attomorrow at 0 am UTC, but I am
> not very sure. If you want to participate in the Taipei meeting, you might
> want to contact Murata-san.
>
>
>
> Other internationalization related EPUB subgroups and topics that are
> beyond EGLS:
>
> - Text Content Subgroup
> http://code.google.com/p/epub-revision/wiki/TextContent
>
>   They are talking about better support for converting dictionaries to
> EPUB[3]. Can Internationalization Tag Set (ITS) be introduced to the format?
>


ITS currently provides no information related to dictionary entries. As [3]
shows, there are already a lot of formats related to dictonaries. The role
of ITS I can see here is to identify what part of a document a dictionary
entry is, and what kind of entry it is (TEI, OLIF etc.). In other words: ITS
could help the interoperability for applications using dictionary entry.
Note, btw., that in its current version ITS does not have such a facility,
so one would need an update of ITS.




>
> - Metadata Subgroup http://code.google.com/p/epub-revision/wiki/Metadata
>
> I also think Google Translate's 'class="notranslate"'  is interesting, but
> I am not sure which EPUB subgroup this feature belongs to. (BTW, EPUB is
> currently based on XHTML which does have namespace support so maybe ITS is
> possible?).
>

It would be good to have a "translate" flag within epub, IMO. To be
compatible with ITS, there is no need to use a namespaced attribute, as long
as the definition of the attribute is aligned with the definition of
"Translate" in ITS (e.g. "has two values 'yes' or 'no'). See
http://www.w3.org/TR/its/#trans-datacat for details.
Regarding class='notranslate': I think that approach has the drawback of
overloading the "class" attribute. Having a separate "translate" flag is
better IMO. Note that i18n core is also going to push within HTML5 for a
separate flag - see http://www.w3.org/2010/09/29-i18n-minutes.html#action02.



>
>
> You might also want to discuss the best solution we have for  "EGLS_O1
> Phonetics in Metadata" [4]. Can ITS cover this?
>


I don't think that you need ITS here, the solution proposed by Murata-san
looks fine to me.

Cheers,

Felix


>
> [1] http://code.google.com/p/epub-revision/wiki/EGLS_requirement_list
> [2] http://dev.w3.org/csswg/css3-text/#line-break
> [3] http://code.google.com/p/epub-revision/wiki/DictionariesGlossaries
> [4]
> http://code.google.com/p/epub-revision/wiki/EGLS_solutions#Solutions_to_Phonetics_in_Metadata
>
>
> Cheers,
> Kenny
>
>
>
>
>
>
>
>
Received on Wednesday, 29 September 2010 20:07:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 29 September 2010 20:07:52 GMT