W3C

- DRAFT -

TPAC breakout

08 Nov 2017

Attendees

Present
Regrets
Chair
SV_MEETING_CHAIR
Scribe
chaals2

Contents


intro

<chaals-o> r12a: Beep

<chaals-o> r12a: The i18n mission is to make the web work worldwide. That's a big job and there are other groups doing bits of it.

UNKNOWN_SPEAKER: We look at things like CSS, Timed Text, HTML, ... and they need to be able to represent text in a way that is recognised as natural by the local users

<scribe> scribenick: chaals2

UNKNOWN_SPEAKER: Japanese has wakiten, which the west does not. Arabic stretches text rather than spaces for justification.
... these are not easy today - and there are complex rules about what you can stretch anyway.
... We need to understand the requirements, and then make sure W3C work can deal with it.
... And it is hard to find english-language explanations of requirements for languages that are not english, like Thai or Sinhalese
... Once upon a time we didn't make a big effort to look for experts around the world, beyond the ones we had. That changed starting with the Japanese Layout Task Force.
... They worked and wrote in Japanese, and then translated their output into english
... describes the unique (or different from english layout?) requirements for layout.
... So how do you support different appraoch to layout in CSS, etc.

[r12a describes ruby usage and layout as a detailed example]

r12a: We get the layout requirements, and then we need to find out what implementations do and what is not supported.
... E.g. people say "yes we can do vertical layout" - but then it turns out that there are unmet requirements, like being able to have latin text included in several orientations at once.
... Now we have a number of requirements documents, and there are more that are in development - and probably more that we should get.
... It is hard. People get enthusiastic and start, and then realise that they need to do a lot of work (write a book, roughly) to describe their requirements, and they slow down.
... We are thinking the best way is to start with the gap analysis - what doesn't work today?
... and then prioritise the gaps, and write that bit up, and some tests, and focus on getting implementors to do that. And proceed iteratively

<Ralph> Chaals: another approach is to go to a university and recruit a student as a PhD project??

r12a: I would prefer to have a group of people than a single student. E.g. Arabic has multiple possible approaches to justification, and one single person may not cover that well.
... Ethiopic lreq is done by one person, and we are concerned about lack of review. But it is something to think about.
... Right now we are trying to work out how many gaps there are.
... we have a matrix https://w3c.github.io/typography/gap-analysis/language-matrix.html
... this is currently a quick draft, not validated.
... There are things that people expect for everyday use, things that are not needed on a daily basis for writing, but important for e.g. basic publishing quality.

jacques Are the question marks things we don't know?

r12a: Right.
... And there are things marked as "it does not work" because it doesn't.
... then we have more detailed explanation for each language

[shows amharic as an example]

r12a: We also have a docuiment on layout and typography - CSS doesn't want to define every single thing about how to handle layout, they want implementors to be able to do it, but this provides implementors with a reference to the requirements we know of.
... There are known unknowns in there, and we have listed them as issues in a github repo

[r12a describes the index of pictures of things that happen]

CMN: Have you considered stuff like braille layout, sign languages, etc?

r12a: Not yet, but we can put it in there.

jacques Is there a test suite to help people detect what is wrong?

scribe: e.g. we have automatic translation. Can we get some text that shows up the problem when you put it in a translator?

r12a: There is the Universal Declaration of Human Rights in 400 languages - but it is a specific format. But basically, no we don't have that. We would like people to come to us and say they have experienced some problem.

@@2: Do you have indicators that CSS will cause problems in specific languages - a checklist that you can say what is going to go wrong?

r12a: Sort of. We have some tests that can sort of be used for that...

@@3: Work done for CSS has been based on requests?

r12a: Yes, or - currently mostly - people who happened to know something was needed.
... We lack a way to find people who are experts in publishing and layout, and know what people want to do

jacques You don't want people to write about CSS...

r12a: Yes. We want to describe the requirements, not the current state of the art.

jacques Want to avoid trying to find an expert in CSS and some language

r12a: We had someone wanting to do gap analysis in the requirements document - or accepting what they think is "good enough" and not including the actual requirements.

@@4: regarding security. There is a discussion about homoglyph phishing. Does this group have scope to look into that issue?

r12a: Other people are working on it and we don't have capacity, so we don't work on that.

@@5: how do you choose which language to work on?

scribe: Mongolian is not used in everyday settings.

r12a: Right. 2.2 million people speak mongolian in Mongolia, generally use cyrillic, but would like to use their own script.
... the matrix has the top 100 languages from wikipedia by usage.
... Which is not really right. There are some unique things for Mongolian.
... In my mind it is important to get it into the list because it has architectural properties that we will not solve if we don't include it in our set of requirements. Same for Javanese.
... So there is a mix of what people want to pay for, whether something is endangered, whether there are unique technical requirements implied.
... And where we can find someone who can tell us something.

jacques 2 major reasons. Want people who speak a language to be able to use the web, and want to use their language, but also to make sure a language doesn't disappear as people just shift to english.

r12a: We are going to try and help people where they come with requirements. We can make contacts in implementation, technical development, etc. But we need subject matter experts.
... And it is hard to convince people that their ordinary knowledge is actually information they have that the rest of the world doesn't.
... So they don't feel confident that they should contribute.

Jacques: How do i18n pages switch language? What's the magic?

r12a: Usually someone has manually done the work - or checked it.

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/11/08 20:04:37 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/example, ruby/[r12a describes ruby usage and layout as a detailed example]/
Succeeded: s/student/student as a PhD project?/
Succeeded: s/We have some eggs but no chickens/Sort of. We have some tests that can sort of be used for that.../
Succeeded: s/@@:/jacques/G

WARNING: No "Present: ... " found!
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy
        <amy> Present+

Found ScribeNick: chaals2
Inferring Scribes: chaals2

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]