Typography and different languages

List overview All Threads
Download

newer

older

Join our Multimedia Meetup - Next...

beta features - RTL icons

Amir E. Aharoni

30 Nov 2013 30 Nov '13

10:49 a.m.

Hi, So, since there are a lot of discussions about typography lately, I guess I have to chime in with internationalization considerations. tl;dr: 1. Bug 57045 should be resolved. 2. Typography changes shouldn't be made default in any language without testing and positive approval. The long version: The discussions about typography need to take into account not just the Latin alphabet, but other alphabets as well. Even within the Latin alphabet there can be variations; for example, Vietnamese and some other languages use a very large number of đìâċṛįṭīçś, which may require use of different styles. Generally, *any* significant typography changes must be tested in all scripts and nothing should be enabled by default in any project without a positive approval from the community or at least from Language Engineering. This is not as heavy and bureaucratic as it sounds, however :) What do I mean by "all scripts"? Basically scripts like "Latin", "Cyrillic", "Devanagari", etc. Their number is much smaller than the ~300 languages of MediaWiki. An easy step to properly creating these groups would be resolving bug 57045 [1], where I propose grouping languages by script names. And here are some actual basic style considerations: * minimum line-height: usually not important for Latin, but often needed for languages of South and South-East Asia. * minimum letter size: languages with complex glyphs and ligatures are usually completely unreadable under 12, and may even need a size of over 14. Examples are Chinese, and many languages of India. * underline: underline is quite bad for writing systems where the letters often go below the baseline, such as Arabic. (This is actually implemented in a very hacky way in getStyles() in includes/resourceloader/ResourceLoaderUserCSSPrefsModule.php and should be refactored.) * uppercase and small caps: this may be useful and nice for Latin, Cyrillic, Greek and Armenian, but other writing systems don't have it. Depending on it for adding elegance or for emphasis is not a good idea. These are the basics. Obviously, there may be more considerations. Another relevant link: https://www.mediawiki.org/wiki/Internationalization/Styling_and_typography [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=57045 -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

Attachments:

attachment.htm (text/html — 3.2 KB)

Show replies by thread

Max Köhler

30 Nov 30 Nov

12:29 p.m.

/uppercase and small caps: this may be useful and nice for Latin, Cyrillic, Greek and Armenian, but other writing systems don't have it. Depending on it for adding elegance or for emphasis is not a good idea./ That's a very interesting problem you bring up.. As far as I can see, we need inline styling for two different cases: - To add emphasis. In my opinion, italics would be the best option here. They don't interrupt the reading experience as bold set words do. - To mark links. Underlining is obviously the standard way to go here, but considering your arguments, a different solution might be better here. I could imagine changing the text color (which would need to be tested to be accessible for people with sight problems) or adding a colored background. Did I miss anything here? best, max @awesomephant <https://twitter.com/awesomephant> ps: hi. I'm the new kid on the block.

Amir E. Aharoni

12:51 p.m.

2013/11/30 Max Köhler <max(a)koehler-kn.de>

...

uppercase and small caps: this may be useful and nice for Latin,

Cyrillic, Greek and Armenian, but other writing systems don't have it. Depending on it for adding elegance or for emphasis is not a good idea.

...

That's a very interesting problem you bring up.. As far as I can see, we

need inline styling for two different cases:

...

- To add emphasis. In my opinion, italics would be the best option here.

They don't interrupt the reading experience as bold set words do. Italics are, actually, a yet another example of a Western-centric typography thinking. They are so commonly used in Latin and Cyrillic that most markup languages and word processors provide very accessible support for them, but they aren't so natural in many other scripts. In the typography of Hebrew, which I speak, using italics is considered bad taste by many, and using bold weight or a different typeface is preferred. That is, more or less, the reason why W3C recommends using rather than . Ideally the ''double apostrophe'' in wiki-syntax will insert (now it inserts ), and we'll have styling somewhere along these lines: .script-latn em { font-style: italic; } .script-hebr em { font-weight: bold; } (Of course, this is just a simplistic suggestion and the actual styling may be different.)

...

ps: hi. I'm the new kid on the block.

Welcome :) -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

max

1:22 p.m.

...

That is, more or less, the reason why W3C recommends using

rather than . Ideally the ''double apostrophe'' in wiki-syntax will insert (now it inserts ) I absolutely agree with your point. I wasn't aware that wiki-syntax inserts in fact tags (and also tags, which bring up the same problems). That needs to be changed. We need clean, semantic markup in order to adjust the styling to any given circumstances, as you perfectly described. Speaking of semantic markup, what do you guys think about replacing the standard 'bold' and 'italic' buttons in the visual editor with a simple 'emphasis' button? In my opinion, that would help a lot with these kinds of problems. In my opinion, we should make authors think less about presentation (that's our job) and more about content. best, max. @awesomephant <https://twitter.com/awesomephant>

Bartosz Dziewoński

1:33 p.m.

On Sat, 30 Nov 2013 13:22:20 +0100, max <max(a)koehler-kn.de> wrote:

...

Speaking of semantic markup, what do you guys think about replacing the standard 'bold' and 'italic' buttons in the visual editor with a simple 'emphasis' button? In my opinion, that would help a lot with these kinds of problems. In my opinion, we should make authors think less about presentation (that's our job) and more about content.

It would also make authors raving mad, which is a reasonable reaction to having your editing tools taken away. VisualEditor already gets enough hate. Many things are traditionally typographically marked in italics – quotes, song titles, regular mid-sentence emphasis, and I likely missed some – and Wikipedias have many rules about what to mark with emboldened text (article lead usually contains bold title of that article, various tables have bold headings, navboxes often use bold for content information). And last but not least, people simply *care how their work looks*. Unless you're willing to replace it with 20 new "semantic" buttons, you can't kill the distinction between bold and italics. -- Matma Rex

Bartosz Dziewoński

1:35 p.m.

On Sat, 30 Nov 2013 13:22:20 +0100, max <max(a)koehler-kn.de> wrote:

...

I absolutely agree with your point. I wasn't aware that wiki-syntax inserts in fact tags (and also tags, which bring up the same problems). That needs to be changed. We need clean, semantic markup in order to adjust the styling to any given circumstances, as you perfectly described.

Peter Coombe

7:08 p.m.

Indeed. See also the bugs where these were set to use and https://bugzilla.wikimedia.org/show_bug.cgi?id=369 https://bugzilla.wikimedia.org/show_bug.cgi?id=370 And subsequent bugs asking for a change to and which were marked as INVALID / WONTFIX. https://bugzilla.wikimedia.org/show_bug.cgi?id=1038 https://bugzilla.wikimedia.org/show_bug.cgi?id=7921 https://bugzilla.wikimedia.org/show_bug.cgi?id=12550 Peter On 30 November 2013 04:35, Bartosz Dziewoński <matma.rex(a)gmail.com> wrote:

...

On Sat, 30 Nov 2013 13:22:20 +0100, max <max(a)koehler-kn.de> wrote: I absolutely agree with your point. I wasn't aware that wiki-syntax

inserts in fact tags (and also tags, which bring up the same problems). That needs to be changed. We need clean, semantic markup in order to adjust the styling to any given circumstances, as you perfectly described.

This sucks, but it can't. The italics and bold weren't always used with the semantic meaning of giving emphasis (as I mentioned in my previous e-mail), so blindly replacing them with "semantic" tags and giving them false meanings would be a step back. -- Matma Rex _______________________________________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

Denis Jacquerye

11:40 p.m.

The and elements were described only in presentational terms, this is not the case anymore in HTML5 where they now have specific semantic purpose: http://dev.w3.org/html5/markup/b.html span of text offset from its surrounding content without conveying any extra emphasis or importance, and for which the conventional typographic presentation is bold text” http://dev.w3.org/html5/markup/i.html span of text offset from its surrounding content without conveying any extra emphasis or importance, and for which the conventional typographic presentation is italic text”. If one wants they don't have to follow the conventional typographic presentation and use for something other that bold text, or for something other than italic text. On Sat, Nov 30, 2013 at 7:08 PM, Peter Coombe <thewub.wiki(a)googlemail.com> wrote:

...

On Sat, 30 Nov 2013 13:22:20 +0100, max <max(a)koehler-kn.de> wrote:

_______________________________________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

-- Denis Moyogo Jacquerye African Network for Localisation http://www.africanlocalisation.net/ Nkótá ya Kongó míbalé --- http://info-langues-congo.1sd.org/ DejaVu fonts --- http://www.dejavu-fonts.org/

Nick White

2 Dec 2 Dec

1:11 p.m.

On Sat, Nov 30, 2013 at 01:51:39PM +0200, Amir E. Aharoni wrote:

...

That is, more or less, the reason why W3C recommends using rather than . Ideally the ''double apostrophe'' in wiki-syntax will insert (now it inserts ), and we'll have styling somewhere along these lines: .script-latn em { font-style: italic; } .script-hebr em { font-weight: bold; } (Of course, this is just a simplistic suggestion and the actual styling may be different.)

I know this was just an illustrative example, but I'm curious whether there's any reason not to use the :lang css construct for cases like this (rather than e.g. .script-hebr)? So you'd set <body lang="hebr">, then use rules like: :lang(hebr) em { font-weight: bold; } I'm just checking that there's no good reason not to use this, because that's what I've been doing with an extension I wrote[0] ;) Nick 0. https://www.mediawiki.org/wiki/Extension:CharRangeSpan

max

1:23 p.m.

As attribute selectors are basically supported in every browser (except ie6), compatibillity isn't the issue here. Not entirely sure here, I guess working with classes is just what people are more used to? --max @awesomephant <https://twitter.com/awesomephant>

...

On Sat, Nov 30, 2013 at 01:51:39PM +0200, Amir E. Aharoni wrote:

Amir E. Aharoni

1:29 p.m.

2013/12/2 Nick White <nick.white(a)durham.ac.uk>

...

On Sat, Nov 30, 2013 at 01:51:39PM +0200, Amir E. Aharoni wrote:

That is, more or less, the reason why W3C recommends using rather

than

. Ideally the ''double apostrophe'' in wiki-syntax will insert

(now it

inserts ), and we'll have styling somewhere along these lines: .script-latn em { font-style: italic; } .script-hebr em { font-weight: bold; } (Of course, this is just a simplistic suggestion and the actual styling

may be

different.)

"hebr" is a four-letter ISO 15924 writing system code. Such things are more oriented to writing systems than to languages. There is no standard HTML attribute for a writing system. If all the languages that use the Hebrew script have the same design it is easier to group them this way. That's what Bug 57045 is about. Of course, it's quite possible that some particular languages would have special properties, and for them it's possible to use :lang(he) as you propose, but with a two- or three-letter language code according to the ISO 639-3 language code.

...

0. https://www.mediawiki.org/wiki/Extension:CharRangeSpan

Jared Zimmerman

4 Dec 4 Dec

11:01 p.m.

I mentioned this at the language summit in Pune, we'll need to add in extra controls to allow for some languages to have more fine grain control of the leading, font size micro-adjustments and in some cases letter spacing of non-latin alphabets. We want to have the same overall weight and texture of paragraphs irrespective of the characters being used. For that to work we'll need to do some one off adjustments for alphabets that are more optically dense or use a lot of diacritic marks that go well above or below baselines. Is there a bug logged for this? *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmerman<https://twitter.com/JaredZimmerman> On Mon, Dec 2, 2013 at 4:29 AM, Amir E. Aharoni < amir.aharoni(a)mail.huji.ac.il> wrote:

...

2013/12/2 Nick White <nick.white(a)durham.ac.uk>

On Sat, Nov 30, 2013 at 01:51:39PM +0200, Amir E. Aharoni wrote:

That is, more or less, the reason why W3C recommends using rather

than

. Ideally the ''double apostrophe'' in wiki-syntax will insert

(now it

may be

different.)

0. https://www.mediawiki.org/wiki/Extension:CharRangeSpan

Curious, I'll take a look. Thanks for the link. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬ _______________________________________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

3795

days inactive

3799

days old

design@lists.wikimedia.org

Manage subscription

11 comments

8 participants

tags (0)

participants (8)

Amir E. Aharoni
Bartosz Dziewoński
Denis Jacquerye
Jared Zimmerman
max
Max Köhler
Nick White
Peter Coombe