Template talk:Braille cell

{{Braille Cell}} upgrades

The {{Braille Cell}} template has a new upgrade. You can now indicate multiple-cell braille patterns with a single call of {{Braille Cell|cell 1|cell 2|cell 3...}}, up to 20 cells. It still takes the exact same named parameters, ie type=, size=, alt=, text=, which are applied to all cells. I may enable cell specific parameters if anybody wants them. Please post any comments here. VanIsaac_WS^contribs 06:33, 29 April 2012 (UTC)

Size; maintenance

Can we have the default (unspecified) size of the Unicode output match the default size of the text? The reader should set absolute font sizes, not us. — kwami (talk) 09:43, 20 July 2012 (UTC)

Not when they are images. These can only be set in px (fixed size), not in em (user font). In general, images are not easily to flow in-line (they are treated as boxes, whereas inline code gets font & textflow treatment. CSS). We cannot rely on Unicode font yet, do we (to show U+28xx on user browsers)? -DePiep (talk) 22:11, 24 July 2012 (UTC)

I mean for text (Unicode) output, which is one of our options. I understand that won't work for images (as with all the embedded text in the rongorongo article.) But rather than shifting to a braille keyboard, or pasting from another article, we could use this template to embed braille within a text. Currently I need to start with that, preview the article, copy the result, and paste it over the template, which is needlessly time-consuming, all because the template does not match the font size it is embedded in. — kwami (talk) 01:11, 25 July 2012 (UTC)

Yes, the font should size to the fontsize. My question was: is that Uncode braille font (font that has Unicode braille) widely available? If it is not around, the user doesn't get the cells by font. (I am working on this offline, into simple single table). -DePiep (talk) 02:34, 25 July 2012 (UTC)

test using {{Braille cell|a|type=unicode|size=4em}} (note: using type=text is equal):

Current live version:
no size set: Abc⠁def	size set to 4em: Abc⠁def	size set to 1em: Abc⠁def
Indeed this is not needed. Current sandbox:
no size set: Abc⠁def	size set to 4em: Abc⠁def	size set to 1em: Abc⠁def
version 2: Allready deployed in live code, so the effect is gone. Size is ignored in text-case.
3rd version (size optionally); /sandbox:
no size set: Abc⠁def (default=100%)	size set to 3em: Abc⠁def	size set to 125%: Abc⠁def

Overview adjusted after second request below. Note that only current versions are shown, so comments can be off the mark.  Done -DePiep (talk) 21:00, 26 July 2012 (UTC)

We might want to set the size. In a table, for example, or even inline we may want braille larger for visibility. I suppose we could do that with external <big>...</big> formatting, but would it be convenient to keep the option in the template? We want the reader to have control, however, so relative size (per markup) is probably better than absolute size. — kwami (talk) 22:59, 26 July 2012 (UTC)

Yep. There is a <span> around the unicode cells now. It takes size now for the text (unicode). Default is font-size=100%, always (no if-clause). Into live (/main only required)? -DePiep (talk) 02:34, 27 July 2012 (UTC)

 Done Optional font-size, with default. Into live, earlier. -DePiep (talk) 23:00, 27 July 2012 (UTC)

The size doesn't work for Unicode output. I've tried various absolute and relative values, and they make no difference. — kwami (talk) 05:31, 29 July 2012 (UTC)

Strange. With me the effect is visible (now in the top row of the example table here):

• default: ABC⠁XYZ
• ABC{{Braille cell|a|type=unicode|size=150%}}XYZ → ABC⠁XYZ
  

-DePiep (talk) 20:04, 29 July 2012 (UTC)

Kwami, still wrong in the ñew sandbox version? -DePiep (talk) 06:42, 3 August 2012 (UTC)

Easier tables

All the duplicated tables make this difficult to maintain, and difficult to root out errors as they creep in. There should be an easier way, crossref'ing a single table of inputs with the output type. — kwami (talk) 21:32, 24 July 2012 (UTC)

Indeed. -DePiep (talk) 22:11, 24 July 2012 (UTC)

I am working on this. -DePiep (talk) 18:36, 25 July 2012 (UTC)

What do you think about a single sub-template that maps the image files by a single, standard input - like Unicode point, dot pattern, or character (used in the example, below)? That way, we can map by the inputs alone, with the type called only to disambiguate, instead of grouping by type and duplicating mappings exponentially as we add input parameters. The type parameter can then be passed to the regularized sub-template to get the right display. Something like:

| B = {{/subtemp | ⠃ | {{{type|}}} | {{{alt|}}} }}
| I = {{#switch: {{{type|}}}
    | Kana | Japanese = {{/subtemp | ⠃ | Kana | {{{alt|}}} }}
    | Korean | Hangul = {{/subtemp | ⠕ | Hangul | {{{alt|}}} }}
    | #default = {{/subtemp | ⠊ | {{{type|}}} | {{{alt|}}} }}
}}
| ぃ | ィ | い | イ | ｨ | ｲ = {{/subtemp | ⠃ | Kana | {{{alt|}}} }} etc.

Does that seem like it would be easier to maintain? VanIsaac_WS^contribs 21:26, 25 July 2012 (UTC)

It would also make multi-cell mappings easier to handle. VanIsaac_WS^contribs 23:12, 25 July 2012 (UTC)

(edit conflict)I am not this enthousiastic about this yours yet. One single input to solve it all doesn't seem workable to me. (It looks like the current template tries to do this, with bad consequences). The editor would have to do homework to use it. For example, he/she would have to type like jap-WO or kor-WO to get it right. Out of sight/mind for even a smart editor -- hey, only five would get it, and that is excluding me.

This is what I have in mind: it should take two inputs, but there is a default. 1. dot-number braille definition somehow. 2. A braille language id (default: English/grade2, option jap & kor present, expect chech or greek?). So anyone can type like language=Korean and go ahead.

Aside: trying to squeeze two steering wheels (braille dots, Korean braille diffs) into one is not manageable in general. I am trying to solve this differently offline. Today I spend time to discern CJK characters).

And I say compliments to VI, for pulling this whole template show up, including the illustrative colored start/stop variants (which sounds funny for braille, but will be OK in the future). -DePiep (talk) 23:34, 25 July 2012 (UTC)

Tagging both the input and output is an interesting idea. My concern is that it may introduce complexity to the end user in order to reduce complexity for the programmer. What do you think about having default input tags tied to each of the output tags, but allow for an explicit input parameter to override the default for a particular output? VanIsaac_WS^contribs 00:19, 26 July 2012 (UTC)

Oops, I did not read your idea carefully enough VI, I read it as "singe input" for the user, but that would be for the subtemplate so a good plan indeed. Even better, that was my line of thinking too! Now a question. In the Korean and Japanese brailles, is it allowed to use English input forms like comma? Or are they purely CJK characters and the coded words ("wo")? -DePiep (talk) 09:26, 26 July 2012 (UTC)

No, the standardized input is just for the rendering subtemplate. The /main template would map all the varied input forms to the standard format to simplify the rendering subtemplate. I think you would definitely need to tag the input if you wanted to support English letters with Japanese/Korean patterns because of things like "I" being either ⠃ or ⠊ depending on whether it's Japanese romaji or English letter input. I don't think there's really any utility to having English input give a Japanese colored braille cell output, even if there might be some argument for romaji input to give unmarked 6-cell output. There is, however, another rather compelling reason to tag input, which is that we can support all the different European mappings of accented letters if we tagged the input as French/German/Spanish/etc. Of course, even if the output images are the same set, you could still overload the type= parameter to allow for tagging of the input by language. It's an engineering decision, and I don't know if you've actually done any coding for an upgrade of the template, but I'd certainly be happy to work on an upgrade with you. VanIsaac_WS^contribs 09:50, 26 July 2012 (UTC)

I understand. I think we should use lang= for the obvious, and e.g. form= for separate choices like "svg" gallery or "inline" unicode font. Current usage of type= in articles to be checked by then, and maybe split along this line. -DePiep (talk) 10:56, 26 July 2012 (UTC)

btw, for that internal single definition (I plan to use indeed) you suggested using the graph like ⠃. You think this will cause no problems ever on browsers & systems? In the exotic font department, my winXP/FF is doing a bad job recognising some CJK characters in this (it even mixes them up). For this internal definition, shall we use the dot numbering: 2357 (unicode style climbing numbers)? -DePiep (talk) 11:04, 26 July 2012 (UTC)

I literally just used that for the example because it was a good visual indicator. I agree that the dot patterns are probably the most intuitive variables to send that are going to be universally readable by future maintainers of the template. I would probably keep the type= parameter as the output variable, but lang= sounds like a good idea - it brings to mind the IETF language tags codes which make a good input format, and we can even use the standard "ar-DZ" syntax for country-specific mappings, if necessary. The 8-dot cell images are named with the Unicode dot pattern syntax, so you are right, in dot order, so it's probably the best input form for the subtemplate. VanIsaac_WS^contribs 11:50, 26 July 2012 (UTC)

I don't see any problem with having separate tables for Japanese and Korean, because they are so completely independent. Yes, romanized input should be supported: the whole point is to make this easily accessible. If we want to use the English-braille "i", then we just shouldn't tag it for Japanese or Korean.

IMO, we should support dot patterns, French values, and English values by default. (French and English conflict w punctuation & formatting, so we'd need to choose in those cases—presumably English, but they don't conflict in the actual letters.) If we want to enter German values, then we should have to specify that it's German. But how often would we need to do that? Would it even be worth coding the template to handle German etc.? And with all the different braille alphabets, where would it end?

Another possibility (was this what vanIsaac meant above?) would be to prefix the input: so "st" would output English-braille "st", but "de-st" (or "st-de"?) would output German-braille "st". Not sure how much we'd use that either, but it would simplify the coding compared to tagging the input for each language. — kwami (talk) 23:05, 26 July 2012 (UTC)

Kwami, would it be ok to have this effect: if language is specified to be Korean braille, and the editor enters "HH" (from grade 2 English), what should happen? Show or no show of that cell? -DePiep (talk) 20:10, 29 July 2012 (UTC)

Sorry if there was some confusion. "ar-DZ" is the IETF code for Algerian Arabic, which has a separate braille system from "ar" - default Arabic. So the lang= tag is intended as a simple language tag, and would be separate from the actual inputs. I agree that inputs should probably be considered English by default, but I think that Japanese/Korean/Arabic/Bharati output would interpret Latin input as romaji/RR/UNGEGN/ITRANS unless otherwise specified. VanIsaac_WS^contribs 00:07, 27 July 2012 (UTC)

I have this scheme in mind. One enters wo and lang=korean braille (language once for the string), plus type=text (or svg). Result is the unicode braille cell for Korean "wo" (wouldn't that be great eh). Default is: lang=English braille. This means: no language entered uses the English table. This includes basic alphabet and grade 2 shortcuts. And this is the great thing: when we want to add French braille, only the exceptions from the default are required (such as punctuation). So the "A" in future French does not have to be redefined.

Only problem was that it took some time to sort the 3500 input options that are now present (in 700 code lines). Expect movements in the sandbox shortly.

Now here is a question: when we add French, the English grade 2 input options (like "have") would still give the English result. Now writing that in a French sentence may not be expected. But my question is: should we prevent it (switch off, blank output for those grade 2 codes when in French)? -DePiep (talk) 02:52, 27 July 2012 (UTC)

I'm thinking that wo lang=ko type=text would display, as unicode text, the pattern for the hangul vowel "wo". On the other hand, wo type=Hangul would display, as Korean 6-cell braille image, the hangul vowel "wo". Likewise, i type=text would give you the English braille "I" as unicode text. VanIsaac_WS^contribs 03:17, 27 July 2012 (UTC)

I don't know if there are French compound letters that would conflict with English ch etc. If there are, then they would need to be specified, which would override the default English. But as w German, I don't know if that would be useful: people can always enter the dot patterns, and there aren't likely to be many who would use the French compound letters anyway. But basic French (ç, ê, etc.) are useful enough to include (they're even listed in the occasional English chart), and d n interfere w anything. — kwami (talk) 04:26, 27 July 2012 (UTC)

Good point. Accented characters can probably be safely assumed to be French, but I think it is possible to take this too far: any accented latin character not mapped to French would be assumed Spanish; not French or Spanish, Hungarian; not French, Spanish, or Hungarian, Vietnamese; etc. etc. etc. I'm not sure how to manage this other than restricting input to the most common (English, French) and unique (Kana, Hangul, Devanagari) inputs possible, and leave the rest to explicit dot listing. VanIsaac_WS^contribs 04:34, 27 July 2012 (UTC)

Yes, I think that's exactly what we should do. French support because it's the original. English support because we're English WP. No-one's going to remember which lang a letter is supposed to be if it's not either of those or in a different script. We could add "lang=de" for German values if someone would use them, but I doubt anyone will. — kwami (talk) 06:20, 27 July 2012 (UTC)

Easier to explain my proposed future situation with sandbox exmplates. -DePiep (talk) 09:42, 27 July 2012 (UTC)

Did you know that this started as a really simple template for a common syntax for text and image braille? Something happened along the way... VanIsaac_WS^contribs 04:36, 27 July 2012 (UTC)

So there is also input like "425" accepted for dots-245 (⠚). Is this alternative numbering used anywhere (outside of svg filename)? Is it a common way of identifying a cell, as used by braille-scolars? Or can we leave it out as being impractical and rarely used? -DePiep (talk) 10:18, 28 July 2012 (UTC)

My impression is that indicating braille dots in spatial order is the more common form. Most of the braille patterns I was seeing when I was doing background on Japanese braille were defined in 142536 order - actually 07142536 order, as the braille systems for directly representing Kanji use an 8-dot cell, which line up their bottom 6 dots with the 6-dot kana cells. VanIsaac_WS^contribs 10:56, 28 July 2012 (UTC)

I didn't know there was kanji braille. All I ever saw was kana. Do you have any refs? If kanji are part of Japanese braille, our article's quite incomplete! — kwami (talk) 04:52, 29 July 2012 (UTC)

It's not an integral part of Japanese braille, it is an add-on, and I haven't seen a full accounting of the system yet. I found it through the jp.wiktionary at [1]. I think it's actually pretty well defined in [2], but my Japanese is too sparse and stale to be able to really get it, so unless I can find a native volunteer, I think we're stuck with cut and paste into google translate. VanIsaac_WS^contribs 05:20, 29 July 2012 (UTC)

It looks like there's also a 6-pt kanji braille.[3] — kwami (talk) 04:11, 30 July 2012 (UTC)

Well, we will definitely not use the "0 7" top line numbering system, because that would introduce a different, 2nd standard. I'll keep the 14253678 sequence next to the 12345678 sequence as input option. -DePiep (talk) 14:06, 29 July 2012 (UTC)

Yeah, 0714... is pretty much a universal non-starter, isn't it? I was even thinking that a Kanji/Kana Japanese implementation actually has to map the kana to different 8-dot/Unicode patterns (bottom six instead of top six) than a regular implementation, but let's not cross that bridge until we get to it. VanIsaac_WS^contribs 22:35, 29 July 2012 (UTC)

From the layout of the pdf, it looks like they've abandoned 8-pt cells: some are 4×2, some 4×4, and some 4×6: a 24-dot cell appears to be a ligature of three 8-pt cells, not three separate cells. — kwami (talk) 04:26, 30 July 2012 (UTC)

SVG backgrounds white/transparent

Some of our svg files have white backgrounds, and some transparent. Cf.

⠉ c	⠙ d	⠑ e	⠋ f

— kwami (talk) 07:42, 27 July 2012 (UTC)

The PNGs just take a while to update. They all seem to be fine now. I've worked my way through the 6-cell and 8-cell images in commons in the last couple days, so they should be close to all updated by now. If you come back in a couple days and there are still any left, check to see if I'm the latest uploader. If not, let me know about them, as I thought I'd hit them all. VanIsaac_WS^contribs 08:28, 27 July 2012 (UTC)

Yup, that was the primary problem. But you missed four of them. (Your last edit on each says you made them transparent, but it didn't happen.) One has been fixed by s.o. else, but File:Braille È.svg, File:Braille Ù.svg, and File:Braille ST.svg are still opaque:

⠌ st	⠮ è	⠾ ù

(è was just taken care of – maybe the other two will be as well.) — kwami (talk) 07:05, 29 July 2012 (UTC)

Yeah, those are all fine, I think you just have some old PNGs lying around in your cache that need to get updated. Try hitting the purge button if those are still wrong for you. Thanks for checking on those. VanIsaac_WS^contribs 07:16, 29 July 2012 (UTC)

No, another editor fixed them while I was posting this. He also cut the file size by 99.5% after you had already cut it by 50%. I wonder what program he's using? — kwami (talk) 07:20, 29 July 2012 (UTC)

No, he didn't. He increased it over 6x - bytes to kilobytes. VanIsaac_WS^contribs 07:45, 29 July 2012 (UTC)

Duh again: I didn't notice the 'k'. — kwami (talk) 08:02, 29 July 2012 (UTC)

Turns out, the old versions of those were created differently from the rest of the braille images, so the update that replaced the white rectangle didn't work on those three. Thanks for catching those. VanIsaac_WS^contribs 07:55, 29 July 2012 (UTC)

"Blank" and ""Space" to be disambiguated

• See this talk about two braille cells mixing up. -DePiep (talk) 12:22, 27 July 2012 (UTC)

Additions, error cat

I added more support: 'be', for example, and filled in some where we had values in one table but not another. Moved ?/QUESTION from its French value to English. Deleted SPACE until we decide what to do with that. Added Category:Unsupported braille input to the default to help track problems (for example, I deleted support for 'space', and nothing popped up). — kwami (talk) 21:17, 27 July 2012 (UTC)

That category is a very good idea. I'm concerned that the documentation subpage has not shown up in that cat, however; there are purposefully erroneous inputs in the examples. VanIsaac_WS^contribs 21:32, 27 July 2012 (UTC)

Duh, I only added it to the unicode table. Now it should work. — kwami (talk) 05:37, 28 July 2012 (UTC)

Argh, it interferes w the default images. You can figure out a work-around. Meanwhile I'll leave it in, temporarily, to weed out the errors (just caught one). — kwami (talk) 05:50, 28 July 2012 (UTC)

Hello world

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The /sandbox version was put into live. Follow up topics deserve a new section. -DePiep (talk) 00:59, 5 August 2012 (UTC)

---

 Gone live -DePiep (talk) 12:41, 4 August 2012 (UTC)

New template

⠓⠑⠇⠇⠕⠀⠺⠕⠗⠇⠙. I've remade the template. It is now in the sandbox. See {{braille cell/testcases}}. More on this later. ⠥⠎⠑⠗⠒⠙⠑⠏⠊⠑⠏ 23:02, 1 August 2012 (UTC)

Cool. Need support for #, ì (= st), kk (= decimal), ll (= cursive), be, to, slash, fraction, cap, emph.

question, ? give French braille, and so should probably be changed to hh. (And have them call an error cat. so we can manually check them.) — kwami (talk) 23:33, 1 August 2012 (UTC)

Straight additions to the lists can be made as you like, go ahead. It is single point editing (add once). See below for the page. I'll check for all recent edits in the existing template too (last 2 weeks may be missing here).

I'll take a look at the French question. -DePiep (talk) 09:32, 2 August 2012 (UTC)

See #Adding French below. Actually, QUESTION was wrong in the English list (at French dots-26 definition)! Corrected. An editor should not be required to translate their input; setting the language should do. As explained below, we should not add the category for possible errors permanently. For a sweep it is OK for some days. -DePiep (talk) 11:41, 2 August 2012 (UTC)

Aah, French question is what you had pointed out... Added # for NUMBER 283c ⠼. (not "numerical index" grade2). Others now are covered too. -DePiep (talk) 13:39, 2 August 2012 (UTC)

Changes

Below will be a preliminary documentation.

• Internally, 3 lists are separated: Koren, Japanese, English/default/abstract input. ("abstract" is the bare cell without language connection, like when writing "cell dots-146 has three dots raised"). This way, list maintenance (editing & adding) is one place only for each input, and easier for editors.
• Also, the file-lists are separated: Japanese (colored), Korean (colored), 6dot b/w, 8dot b/w. for easier maintentnace. Even when type=6dot defined, the 8dot cell is shown for 8dot input (dot 7 or 8 raised). Better a show than an error I'd say.
• Main settings options: type= (6dot, 8dot, text, Korean, Japanese; default=6dot) as before. New: lang= (Japanese, Korean, #default=English/abstract).
• Error messages (could be turned into tracking-category when going into live).
• Some error-situations maight give different result (e.g. notthe general Braille cell image).
• Blank cell shown when a parameter is skipped: ...|T|h|e||d|o|o|r}}.
• added an opaque grey background color for text cells (unicode characters). Without such a reference outline, exact position of the dots is difficult to see.
• Standard caption added (mouse hover text). Also for text cells (unicode characters). Option set to caption =<blank>. No possibility to set this text manually.
• ALT-text for images (see wp:alt). An image should have a descriptive altenate text for when the image is not available. Looks like a caption, but only describes the image, does not interpret it (the caption can). Alt text shows when images are not available (speech computers, no-image browser setting for speedy loads, etc.). Since this is braille, I thought this one should be perfect for wp:access (think speech computers).
• Current usage covered (except for error-messages. These will be turned into track-category adding when we go into live). No code changes required in ~90 transclusion pages. -DePiep (talk) 08:26, 2 August 2012 (UTC)
• Removed: options alt= and text=; now present by default (caption, alt-text, title). -DePiep (talk) 13:41, 2 August 2012 (UTC)

Pages and lists overview

• Testpage: {{Braille cell/testcases}}
• Overview old/new:

{{Braille cell/overview}} (former: /types) -- {{Braille cell/overview/sandbox}}

{{Braille cell/overview Japanese and Korean braille}} -- {{Braille cell/overview Japanese and Korean braille/sandbox}}

• Input lists: {{Braille cell/english&cell2dot-id}} (all English & default input), {{Braille cell/main/sandbox}} (Kor, Jap input)
• Other, internal lists: {{Braille cell/dot-id2character}} (text characters), {{Braille cell/dot-id2filename}} (6dot files, including jap and kor colored sets), {{Braille cell/dot-id2filename-8dot}} (8dot files).
• Code: The template is nested four deep:

{{braille cell}} uses {{braille cell/main/sandbox}} uses {{braille cell/main2}} uses {{Braille cell/core}}. -DePiep (talk) 08:52, 2 August 2012 (UTC)

Documentation (preliminary)

Japanese and Korean aspects

• Old style like type=Korean is unchanged.
• New: Use type= to choose the image set: 6dot/8dot/text (6dot is default). And lang= to set language Korean/Japanese/English "coloring"(English&general is black&white, default). They work together:

type=	lang=	shows	note
<not used>	<not used>	6dot b/w	default, unchanged
6dot	<not used>	6dot b/w	unchanged
Korean	<not used>	6dot colored Korean	unchanged
8dot	<not used>	8dot b/w	unchanged
text	<not used>	character (is always 8dot)	unchanged
6dot	Korean	6dot b/w	new option
8dot	Korean	8dot b/w	new option

Adding French

As a extra test for maintainability, we'll add French braille.

• Step 1: Check or add non-conflicting characters in the English/default list. e.g. adding ç=12346, ⠯, does not exist or confuse with English. ç is defined in grade2 and for the same cell. OK then, need an other example. -DePiep (talk) 12:05, 2 August 2012 (UTC)
• Step 2: In the {{braille cell/main/sandbox}} we add the exception-by-language list. As are Japanese and Korean. Actually, I added that before. Essentialy:

...#switch: by language
.
.
.
 | fra | french | french braille = {{#switch:{{uc:{{{1|}}}}}
 | = 0<!-- catch blank input before anything else -->
 <!-- todo: french exceptions -->
 | #default = {{braille cell/english&cell2dot-id|input={{{1|}}}}}
 }}<!-- end switch list French -->
.
. (other languages and #default=English go here)
.

-DePiep (talk) 10:55, 2 August 2012 (UTC)

• Step 3: Add actual exceptions (exceptions to English/default braille).

For example the question, ? (mark): [4]. English: ⠦ dots-236; French: ⠢ dots-26.

Added CURRENCY to French exceptions: ⠘ it is not defined in English (grade2), so the word should not be recognised (confusingly suggesting it may be used in English). -DePiep (talk) 11:56, 2 August 2012 (UTC)

• Step 4: Test our additions

lang=French: ⠁⠢⠢; lang=default (so English): ⠁⠦ (Incidentally, I had to correct the English list [5]!)

• Step 5: Add documentation: note that lang=French is added.

Discussion

Kwami, indeed we could add the tracking category for "?' and "question". That would do: every page that uses input Question or ? would be reported. We can not see whether the editor intended French input. Also in the future. I suggest we do so temporally, for a sweep. Could be done now already in the live template. We definitely should not add that category to catch all possible editors errors, such as not specifying the language. -DePiep (talk) 11:30, 2 August 2012 (UTC)

Other issues

• Speed & size: the template was slow, and may be even slower. I had to splice {{Braille cell/overview}} (aka /types) to speed it up (old style, new style!). So many braille cell template on a page might become slow.
• Default sizes: text=150% 100% (font-size), image 40px. -DePiep (talk) 12:11, 2 August 2012 (UTC)
• Image size defalt is big. Make it 20px to give the impression of a line of text? -DePiep (talk) 01:22, 3 August 2012 (UTC)
• Any usage (need) for the option: input to be written below the cell (as a caption)? -DePiep (talk) 01:22, 3 August 2012 (UTC)
• As per /testcases, input {{Braille cell|0|1|2|3|4|5|6|7|8|9}} will output the J, A, B, C, D, E, F, G, H, I cells. Lone numbers should output as dot patterns, ie, blank, A, comma, apostrophe, accent, contraction, capital sign, 8-cell capital dot, 8-cell alt dot, error. VanIsaac_WS^contribs 05:27, 3 August 2012 (UTC)

  What do you think about leaving the numbers alone, but adding "one", "two", "three", &c. Braille patterns are probably the main way that they are going to be entered for any new languages, so I'd hate for dot patterns to have two separate input methods depending on whether it's a single dot or multiple dots. VanIsaac_WS^contribs 05:46, 3 August 2012 (UTC)

Demo at testcases#numbers. I'm fine with the rule: "#1"=number one, "1"=dots-1 cell. Esp since you say that entering by dotnr will be common. (I have added option "dots-1" input, but that is a bit of a workaround, I'd be glad to drop that). Do you think editors will need "one" as input? If we stick to just one problem: explain the diff between "1" and "#1", we are home early. So: shall we do as you propose (#1/1)? and not add "one"? -DePiep (talk) 11:58, 3 August 2012 (UTC)

I definitely think we're fighting against usability making 2 = ⠃, 3 = ⠉, etc. if 12 is going to be ⠃; 14, ⠉. If you didn't have a compelling reason to change it to start with, then I would definitely encourage removing the conflicting input formats. I personally think that #2, #3 is probably going to work fine, but there is one concern - when we start implementing multi-cell inputs, #2, #3 might be interpreted as ⠼⠃ and ⠼⠉. I'm just wondering if we want to have the words "one", "two", "three" as an unambiguous means of specifying the single a-j cells by their numeric values.

No, there were no tough reasons to change it -- I just didn't oversee it then.

Multicell input? As for multicell output, there is no problem. Entering "#2" will still give ⠃, and we could add "##2" giving ⠼⠃. The input list inside will control which input gets a 2-cell output. No string-parsing as you seem to think, just recognising in the list.

"two" is ambiguous from thestart: would that be cell ⠂ or value ⠃? And this for an addition we can choose to add. If we leave "two"-series out, no new ambiguous option. Good! Any "easy for editor" in this is for the insiders only. I prefer leaving those out.

Well, "2" is a conflicting (ambiguous) input. We just ease it by being simply & clear: explain "#2" and "2". Conclusion: Input "#2" is for numerical value 2, input "2" is for cell dots-2. -DePiep (talk) 13:38, 3 August 2012 (UTC)

Done. Changed the input list accordingly. Did not add the "two" series. Please take a check at the /testcases. -DePiep (talk) 13:50, 3 August 2012 (UTC)

Todo

Todo before we can put this in live code:

• Check workings. Check pages are mentioned above: testcases & overviews. Japanese, Korean, other (by language, by type). Do a {{braille cell ... preview in articles.  Done by checking tracking categories. -DePiep (talk) 12:39, 4 August 2012 (UTC)
• Change error messages into Category:Unsupported braille input tracking category or the temporal Category:Braille pages needing attention - (later on).  Done -DePiep (talk) 12:34, 4 August 2012 (UTC)
• Check & add recent changes to the live input lists [6]. Edits after July 15 or so could be missing.-DePiep (talk) 08:26, 2 August 2012 (UTC)

 Done. [7] -DePiep (talk) 13:29, 2 August 2012 (UTC)

Adding 'num' for number, parallel to 'cap' for capital. — kwami (talk) 00:47, 3 August 2012 (UTC)

• Check & edit alt= usage old style: new default alt should do. Six pages: Japanese braille No (kana) Re (kana) Ri (kana) Ro (kana) Ru (kana) (talk) 12:34, 2 August 2012 (UTC)  Done -DePiep (talk) 12:34, 4 August 2012 (UTC)
• Solution for ], escape needed. -DePiep (talk) 13:17, 2 August 2012 (UTC)

Because entering "]" disrupts: ⠁⠠⠶⠶⠄⠉ .. or so it was yesterday. Solved in the process.  Fixed. -DePiep (talk) 23:15, 2 August 2012 (UTC)

Comment

The grey background is a good idea, though we should be able to override it (say for extended text where we don't need it). I think the default text size should be 100%. If someone can't read that embedded in a text, they can't read the rest of the text anyway, and we should let the reader decide how large they want to display the text. Also, the change in size screws up line spacing and makes it look like we have paragraph breaks when we don't. The editor can always set it to 150% for a one-line example or in a table.

 Done. Text size 100%. Option background= (e.g. #45A052, yellow, transparent). btw kwami, does this fontsizing work with you now? -DePiep (talk) 01:17, 3 August 2012 (UTC)

I don't see a problem w default rec. of CURRENCY. There's no conflict, and s.o. might find it easy to use.

No conflict indeed. But it is not English braille, so shouldn't be there. Any non-English/generic usage must have a language specified (three are supported). Someone using French but not entering the language: we cannot help you. Someone writing in English and still getting a result from "Currency"? Our mistake. We should not even suggest it can be used in English. Such "ease of use" is misleading. -DePiep (talk) 01:17, 3 August 2012 (UTC)

What about "asterisk"? English-braille users might expect a 2-cell output. Would including abbreviations slow things up too much? What about just the one-letter contractions?

Asterisk = * is ⠔ right? Is there a 2nd definition? On two-cell output see below (VanIsaac). Adding abbreviations is not limited for that reason, but it should be practical (full spelling and zero to two variants should do). You must also document it you know. If you mean grade2 contractions: I think we must add them. How many contractions & such are there in grade2? -DePiep (talk) 01:17, 3 August 2012 (UTC)

Asterisk is ⟨⠔⠔⟩ in English braille.

There's a complete list at English braille. The contractions I wouldn't worry about so much (though the one-letter contractions are trivial), but the abbreviations might be worth considering—after we get this on line. — kwami (talk) 06:40, 3 August 2012 (UTC)

You can add non-problematic input to the sandbox lists right now (also keeping up with the live template, e.g. "NUM"). english and Jap/Kor/French. List-changes don't have to be done all before going live, that can continue afterwards.

Double-cell output: not a small issue, and currently not correct. Still, I suggest to get the sandbox live without it. After all, it does the same (wrongs) as the current old version. When 2-cell comes available, we can check all of the related input (apostrophe &tc), maybe using the tracking category. -DePiep (talk) 12:41, 3 August 2012 (UTC)

For UEB punctuation, where say "(" is defined differently, should we just expect readers to enter each cell individually [so "5-gh" for "("]? That way we wouldn't need a separate language encoding for UEB. (And to accommodate UEB we'd need to abandon our 1-to-1 output.)

Any link for clarification on UEB? So in UEB the two characters "5 gh" encode a single asterisk (cell)? Looks possible. We can add "5 gh " to the list right?

The second issue is more difficult. (French and Antoine too?). Have UEB - grade2 conflicting definitions? What happens wrong when we put all of them both in the English list? -DePiep (talk) 01:17, 3 August 2012 (UTC)

As long as we're 1-to-1, there's no conflict. But UEB makes distinctions that Grade 2 does not. So, "(" would trigger ⟨⠶⟩ in G2 (it's currently not implemented), but if we accommodated 2-cell output for UEB, it would trigger ⟨⠐⠣⟩ there. But no reason to add "5 gh" to the list: that's just two cells coded as two cells. — kwami (talk) 06:36, 3 August 2012 (UTC)

I see. My thought now: keep all in one (English) list preferred. Then we state: "UEB prevails", unless one specifies "lang=G2" (or vv). -DePiep (talk) 12:50, 3 August 2012 (UTC)

What does your comment on ] mean? — kwami (talk) 20:04, 2 August 2012 (UTC)

Old bug. It disappeared overnight. -DePiep (talk) 01:17, 3 August 2012 (UTC)

I think we're almost going to have to support two-cell output. Japanese braille is complex enough that it would really profit from supporting it, eg the syllable きゃ and ちゅ are represented by the braille ゃ + か and ゅ (or ゃ or ょ) + つ, because the vowel represented in the small yōon is represented by the main vowel in braille. I don't even have a japanese script input that will let you enter the syllables ぎゃ or ぴょ because the diacritic on the main kana joins with the yōon to make a combined prefix in braille. Being able to push a simple syllable like じょ and get the correct braille cells is probably an important long term goal. VanIsaac_WS^contribs 20:37, 2 August 2012 (UTC)

Two cell output. Sounds good, looks possible. It's just: let's first make this version stable and push it into live. Then a next round can come with 2 cell output. Gives us time. Adding it to this version will not speed up anything. -DePiep (talk) 01:17, 3 August 2012 (UTC)

No no no, not right now. You're doing WAY too much fiddling for adding a whole other functionality to be remotely productive. I just want to make sure we don't implement any architecture that makes it impossible to do. VanIsaac_WS^contribs 01:52, 3 August 2012 (UTC)

Postponed then. Indeed would be good if a user does not have to de-compose its input. -DePiep (talk) 07:25, 3 August 2012 (UTC)

Caption text

What do you think about caption=no being a blank mouseover text, with caption= being the unicode character + dot pattern text. Maybe we should add the unicode code point to the caption=yes and caption= texts. Thoughts? VanIsaac_WS^contribs 05:51, 3 August 2012 (UTC)

First a documentation recap:

• Alt-text: . When no image available, a regular text link like this is shown instead, eg input=C: ⠉ (braille pattern dots-14). Fixed for WP:ALT reasons. With images only, not text.
• Caption=yes: ⠁⠁⠀⠶⠦ (input echo)
• Caption=no: ⠁⠁⠶⠦ (reproduces alt=-text) no caption.
• Caption=<blank>|: ⠉⠁⠁⠀⠶⠦ ("" input for caption but not omitted, so no captext at all) alt-text cell definition. -DePiep (talk) 07:25, 3 August 2012 (UTC)

It's the caption=no that I think should be changed to actually display nothing, rather than the alt-text default, which I think is a good match for a caption= blank input. Also, will caption=TexT output "TexT", and should it? If so, I'll implement cell-specific captioning for it. VanIsaac_WS^contribs 07:58, 3 August 2012 (UTC)

 Done the yes/alt/blank options. Caption=no → no caption at all, caption=<blank> → "cell definition" (alt-text), otherwise → "input = cell definition". See testcases section. -DePiep (talk) 10:54, 3 August 2012 (UTC)

(edit conflict)

VI, yes, these are old constructions that remained. Time to review them. We could do this, adding a fourth option:

• Caption=<omitted> (default) → "input = cell definition"
• Caption=<blank> → no caption
• Caption=alt → "cell definition"
• Caption=AnyText → AnyText (free; only the word "alt" is reserved)
• Alt-text: "cell definition" (unchanged)

Note that the AnyText would be the same for each cell in the row!

As long as we keep the 20 separate calls to the /main subtemplate in the base {{Braille cell}} template, then this is an easy fix - you can make separate caption1=, caption2=, caption3=, caption4=... parameters to enable control of the caption text for each individual input. Simply change | caption = {{{caption| }}} to | caption = {{{captionN| {{{caption| }}} }}} for each of the /main subtemplate calls. It will then display individualized captions for those with separate caption texts, and the general or default caption text for those not individually defined. VanIsaac_WS^contribs 08:51, 3 August 2012 (UTC)

Useful? Any current usage other than alt-text like Ra (kana)? The three coded ones we can reorder as we like. The word "alt" is reserved in this (any input "alt" will go unexpected but not wrong). My only point: the option "alt" is will be unknown & unused, while it is a 2nd best alternative (eg when one enters dot numbers, which do no add info to the caption). Proof: the alt-option has disappeared from your listing here ;-).

I really don't know what you're talking about here. VanIsaac_WS^contribs 09:07, 3 August 2012 (UTC)

"Usefulness" - about AnyText option, see below. "Alt is unknown" let's forget that. -DePiep (talk) 11:45, 3 August 2012 (UTC)

Adding Unicode code point I do not prefer here - well, first impression. That would be adding info that is not available in the surrounding text. OTOH, adding after the default (yes) text could be OK (that would be "U+28xx" then, not HTML "&#x28xx;" nor "&amp#13456;" right?). AnyText should be free for the editor. -DePiep (talk) 08:16, 3 August 2012 (UTC)

Yeah, I was thinking "⠭ (Braille dots-1436) U+282D". VanIsaac_WS^contribs 09:10, 3 August 2012 (UTC)

Breeding on this. Is speed getting an issue? See below. -DePiep (talk) 11:45, 3 August 2012 (UTC)

 Done Added U+28xx to the caption (not to the alt-text). If speed is an issue, this one should go first. -DePiep (talk) 09:32, 4 August 2012 (UTC)

On entering "Any Text" in a caption. Should the editor be able to write text for the caption?

1. Usefullness? Already the option text= is available. This sets the caption (one for all characters). Page Ra (kana) (and five others) use that option to give a textual form of the image. This is going to be covered by alt & cap texts (Unicode braille character). Otherwise, text= is not used. More broadly, I want to ask: what use would there be? What AnyText information would one add to the caption? Most often, such info is already below the image in the braille overview tables.
2. Its just a caption, and a hover text at that. The caption should support the image, but should not be an independent information point that adds info that is not in the article elsewhere. A first guide is wp:cap. It says interesting things about the image caption. But then, it is about the caption text visible below the image. Our caption here is the hover-text.
3. Speed & importance. Well it should not be an issue, but the pages with this template are (getting?) slow. I have split the /types page because it did not preview any more (error before finishing; this was with the old template too). I'd prefer that one can use the template as much as needed in an article, without holdbacks for preview & save speed. Now there is some leeway in this, but I suggest not to spend much code & time on secondary (tertiary) text-options. Eg future 2-cell output could take also some extra time to perform, and I think that is more braille-essential. Adding 20 individual options adds a lot of code for a less-used option. Another indicator is: can we document it well enough so that one is invited to use it? I don't think so. Btw, do you also perceive slowness with the old/new template? -DePiep (talk) 11:45, 3 August 2012 (UTC)

Gone live

 Done Gone live. -DePiep (talk) 12:41, 4 August 2012 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Comments, error reports

• I noticed that we no longer display default images on error. Was that intentional or did something get accidentally dropped enabling the error category? VanIsaac_WS^contribs 13:06, 4 August 2012 (UTC)

Yeah, a blank cell dn work. — kwami (talk) 23:52, 4 August 2012 (UTC)

Intentionally. The blank cell was meaningless, no connection between the error and the image (+braille link). There is/was an error-text (in red) when the input was not recognised, but it was commented out before going live to prevent disturbances in existing usage. After the change is stable & checked for this error (tracking category), I think we should turn it on again. Effect: the editor sees the red error/warning message right in preview or after saving. btw, there is no such error article in Category:Unsupported braille input (I only had to edit Japanese braille, infobox). kwami, a typo? -DePiep (talk) 00:08, 5 August 2012 (UTC)

But it's not meaningless as we go live, it's just wrong. — kwami (talk) 01:16, 5 August 2012 (UTC)

exactly what is wrong? And what did you mean with "a blank cell dn work"? -DePiep (talk) 01:18, 5 August 2012 (UTC)

It doesn't work as an indication of an error. It simply breaks the line up into smaller words. Unless you sight-read braille, it would like fine. — kwami (talk) 05:25, 5 August 2012 (UTC)

It didn't used to display a blank cell, it showed the File:Pictograms-nps-accessibility-braille.svg and File:Braille8dotCellNumbering.svg images for an error, and linked to Braille - mostly for lack of a better target. If we're going to have braille error codes, we could actually have it link to a specific error subpage now. VanIsaac_WS^contribs 05:50, 5 August 2012 (UTC)

It doesn't work as an indication of an error. - Again: an error message was used in the sandbox, but it was only switched off when going live (spashing error-messages on existing pages would be disruptive). I plan to switch it on. It was noted in the #changes list above from the start, and existed the whole week in the testpages.

I definitely do not want to use the image as an error message. To me, the image used does not signify "input error". It is more like covering the error. Likely the editor then leaves it there, the reader with a problem to solve.

What would be the equivalent for such an error image when using type=text?

Put simply: shall I put the error message on then, like it was in the sandbox? -DePiep (talk) 17:14, 5 August 2012 (UTC)

(now gone) error input did not show a blank (braille) cell, but a blank ("" nothing). -DePiep (talk) 13:04, 6 August 2012 (UTC)

• Error messages live now. Demo: {{braille cell|xyz}} → Same for type=image/text. No such errors in mainspace now. Page name will also show in Category:Unsupported braille input.

Also an error message when more than 20 characters are entered.

Visible in /overview and /Japanese and Korean overview.

This means: no images used in error situation (re Vanisaac), error message visible in page, no hidden or invisible error (re kwami).

Note: /sandboxes are used for different development now, so I could not demonstrate there. -DePiep (talk) 13:04, 6 August 2012 (UTC)

That works!

BTW, some other templates are set up so they themselves don't appear in the error cat, but I forget the code for that. — kwami (talk) 18:29, 6 August 2012 (UTC)

Glad you like it. The second part? Do you mean: only Articles should be in the cat, no Template pages and no User pages? Can be done, it's just that testing & developing pages will also not show there. I prefer Aricles only. Do so? -DePiep (talk) 22:32, 7 August 2012 (UTC)

Unless there's a reason to include testing pages & the like, I would prefer it without them. It's annoying to visit an error-tracking category to fix the errors, only to find that they aren't errors. When all errors have been fixed, the category should be empty. IMO at least. If there's a reason to link to some other page, that can be manually written into the cat page, so that it provides the link but still registers as empty. — kwami (talk) 04:43, 8 August 2012 (UTC)

Agree, and done. (the reason why testpages should be reportd iseh testing). -DePiep (talk) 11:25, 8 August 2012 (UTC)

Future features

During the previous develpment weeks into the current version (live ~4 August 2012), some issues were shelved. Time to address them. Please keep it to one topic per section (message to myself too). -DePiep (talk) 16:05, 9 August 2012 (UTC)

Expand G2 coverage

See kwami on this, above. Additions to the English list ({{Braille cell/english&cell2dot-id}}) can be done always btw, that doesn't need reprogramming. -DePiep (talk) 16:05, 9 August 2012 (UTC)

Added, using multicell output to default (English G2):

• asterisk * ⠔
• brackets [a] ⠠⠶⠁⠶⠄
• ditto 〃 (U+3003):⠐⠂⠐⠂
• ellipsis ⠄⠄⠄
• NDASH x MDASH ⠤⠤⠭⠤⠤⠤⠤
• g2: single q , double q; open, close:

{{braille cell/sandbox|‘|a|b|c|’|0|0|“|d|e|f|”|size=20px}} ⠠⠦⠁⠃⠉⠴⠄⠀⠀⠦⠙⠑⠋⠴

French braille & other languages

French exceptions can be added. At the moment, French is not complete so not formally supported. Other languages can be proposed. -DePiep (talk) 16:05, 9 August 2012 (UTC)

AFAICT French is fully supported apart from punctuation. We could have inputs "French ?", "French cap(ital)", etc. to cover that. — kwami (talk) 16:20, 9 August 2012 (UTC)

Adding French ? = to the English/default list I do not want. It would work, but it disturbs the basic logic. Of course editors like kwami would get it (and work more easily), but the other, new editors would not get it. Eg when to add the word "French"? Should we cover "French w" somehow? And just think of what would happen if we add more languages to this? I say: most stable solution is, English (G2) is standard, and use lang= for other languages. We can promise this for other languages too. So I say: English is standard, and use lang= for others. We can promise that in this template for a long time ahead. -DePiep (talk) 21:46, 9 August 2012 (UTC)

French exceptions (or regular) punctuation: ⠂⠆⠒⠢⠖⠦⠴⠶⠤⠄⠌⠔. Did not go into math characters (needs multicell). -DePiep (talk) 23:23, 10 August 2012 (UTC)

Disambiguate UEB and G2

Kwami wrote above [8]: For UEB punctuation, where say "(" is defined differently, should we just expect readers to enter each cell individually [so "5-gh" for "("]? That way we wouldn't need a separate language encoding for UEB. (And to accommodate UEB we'd need to abandon our 1-to-1 output.)

The example: ( in Grade 2: and in UEB: ⠐⠣

How to handle this? First: do not worry about multi-cell output here, expect that to arrive (see #Multicell output). Now we can do:

1. kwami's suggestion: use different input code for "(", UEB/G2. Will work, but not easy editing I'd say.
2. We declare G2 default, an editor wanting to use UEB must define lang=UEB to get these ambiguities right; other codes will be OK. There is no check on what the editor does (we cannot guess his intentions).
3. We declare UEB default: mirrored situation.
4. We declare none default: whenever an ambiguous code is entered (like example code (), an error message is shown: "Please enter lang=UEB or lang=Grade2".

Since ⠶ for () is older, even in the UK, and UEB can always be entered as individual cells, I say go w G2 as the default. (We also don't have a complete listing of UEB.) We do want a default: we don't want to make people start specifying language just because they want to indicate ⠶.

Or, we could use "()" for ⠶, and "(" for ⠐⠣, but that might get confusing. — kwami (talk) 16:15, 9 August 2012 (UTC)

That last one, the confusing one, we do not want (quite the opposite).

So since G2 is the most commonly used, I understand, we take that as default (no UEB exceptions/additions/mixups in G2 list). Only and surely when the editor adds: lang=UEB the "(" will return ⠐⠣ and all such UEBs. Note that I steer away from double-coded input like "5-gh". Could be a conclusion (unclear). -DePiep (talk) 16:27, 9 August 2012 (UTC)

More clear: kwami proposal I agree. A conclusion then? -DePiep (talk) 21:52, 9 August 2012 (UTC)

More simple: English G2 is default. UEB should be entered alike French or Japanese. Wil work. -DePiep (talk) 22:01, 9 August 2012 (UTC)

UEB is huge [9]. Very systematical (eg. does tabes and markups), but not suitable for this template. -DePiep (talk) 23:28, 10 August 2012 (UTC)

Possible issues

When changing into multicell output, possible errors:

QOPEN QCLOSE BRACKET

Multicell output

One code input could give two or three braille cells output.

• [ → ⠠⠶. (Vanisaac is working on this in the /sandboxes I think). -DePiep (talk) 16:05, 9 August 2012 (UTC)

  Yeah, I've been working on it. I think I might have hit on the issue, so I'll try it out really quickly and see if it works. VanIsaac_WS^contribs 19:37, 11 August 2012 (UTC)

OK, but omit the "quickly", promise? Go as you like, take your time. We're editing for fun. -DePiep (talk) 19:51, 11 August 2012 (UTC)

Started sandboxig.

• What are the multicells for Japanese braille? I found input:

きき =?

きゅ =?

ぎょ =? -DePiep (talk) 21:45, 13 August 2012 (UTC)

Examples shown in {{braille cell/testcases}}. Seems to work. Need to add some more quotation marks. -DePiep (talk) 23:52, 13 August 2012 (UTC)

Ugh, that's some ugly code, having separate lookups for each of the cells. The "きき" input was just to test out a three-cell implementation, and can be simply decomposed to き + き. There are all sorts of double cell inputs for Japanese that we'll need to define, but for testing, きゅ = and ぎょ = . VanIsaac_WS^contribs 10:38, 16 August 2012 (UTC)

Added in this edit [10] (did some cleanup too). {{braille cell/sandbox|きゅ||ぎょ|lang=jap|type=text}} → ⠈⠩⠀⠘⠪ late signing: -DePiep (talk) 00:36, 17 August 2012 (UTC)

Ugh, that's some ugly code says the one who left us this. -DePiep (talk) 00:40, 17 August 2012 (UTC)

Hey, that's perfectly legitimate code, it just didn't exactly respond well to the expansion when we started having multiple cell types output. VanIsaac_WS^contribs 09:08, 17 August 2012 (UTC)

Your judgement is no contribution, and is not about legality.

Now I did try an other setup, alowing | DITTO | 〃 = 5 2 (both cells in one place). Problem is that cutting up the string into the parts (5, 2) takes way too many resources (newPP limits). I have no more idea on how to go ahead with this. Do you? -DePiep (talk) 14:11, 17 August 2012 (UTC)

Caption below

I am thinking of the option to put the caption (input) below like this:
P. Often appears this way in tables. -DePiep (talk) 16:05, 9 August 2012 (UTC)

That could be useful, esp. if it covers G2. But it wouldn't be a replacement for the current tables. More likely for running text. — kwami (talk) 16:16, 9 August 2012 (UTC)

Current tables can stay. In new tables, this form could occupy a single table cell, saving the editor to create a separate row or celll for the text. In running text it should work fine too, in inline (Unicode) text it might break up the line spacing (adding a sub-line in a line), but it would still be possible. -DePiep (talk) 16:36, 9 August 2012 (UTC)

A quibble: the output should not be ⟨P⟩, but ⟨p⟩. — kwami (talk) 07:36, 10 August 2012 (UTC)

Then the input should be lowercase. Interpreting the caps modifier is nigh impossible (that would be multi-cell input). -DePiep (talk) 09:04, 10 August 2012 (UTC)

As long as it doesn't force caps, we're fine. — kwami (talk) 01:09, 11 August 2012 (UTC)

Agree. We cannot (should not) force lowercase caption either. Editor's input is passed on. -DePiep (talk) 02:51, 11 August 2012 (UTC)

 Not done. Too complicated for now. -DePiep (talk) 11:50, 2 September 2012 (UTC)

Table row

Since the cells are often in tables, we could add the || table code as an option table=yes, so one row of table cells can be defined in one template call, instead of per table cell. -DePiep (talk) 16:05, 9 August 2012 (UTC)

Is there any way for tables to recognize the size of the braille output, and adjust the row height to match? Take a look at Chinese Braille, where I started converting the tables. — kwami (talk) 05:32, 10 August 2012 (UTC)

Can't find why that fails. might need workaround (image?)-DePiep (talk) 07:32, 10 August 2012 (UTC)

 Won't fix. Workaround solution:

• Set fontsize onece for the table (or row), let braille cell at 100%:

{| style="font-size:2em;"
|-
| {{braille code|...}}
|}

Or: set fontsize once per row in style

{| 
|-
| A | style="font-size:2em;"|   {{braille code|...}}
|}

-DePiep (talk) 14:37, 23 August 2012 (UTC)

Other issues

• Param bg does not seem to work. -DePiep (talk) 23:56, 11 August 2012 (UTC)

Solved in the sandbox. -DePiep (talk) 16:13, 14 August 2012 (UTC)

 Fixed in the live version too. "bg=" param now works. -DePiep (talk) 10:23, 16 August 2012 (UTC)

Revisit: Decimals and dotnumbers (and #)

Earlier, we concluded: dot number uses straight digit, decimal number = like #2. To show the braille number sign # sign, we must add it:

• Current: {{bc|2|#2|#|#2}} → ⠂⠃⠼⠃

But now that we can do multicell (sandbox today), wwe are in a hole. Most intuitive would be:

• Proposed: {{bc|2|#2|dots-2}} → ⠃⠼⠃⠂, (add the braille # when #2 input). Leaving "dots-2" a bit strange. Change this input option? -DePiep (talk) 23:39, 13 August 2012 (UTC)

I'd say no, because we still want to be able to specify a character by dots.

Also, ⠼ is not braille for ⟨#⟩. #2 would be ⠠⠝⠕⠼⠃. — kwami (talk) 20:49, 14 August 2012 (UTC)

Corrected my example: to get cell dots-2, we use a separate input option. So the proposed input options are:

"2" for digit 2 ⠃

"#2" for braille marked number ⠼⠃ (two cell output)

"dots-2" (and "dot-2" too) for dots-2 cell: ⠂.

"#" may not be defined "Number" in G2, but we do use it this way (in the template), and there seems no misunderstanding. It is our code. Thus using "#" for the number shifter is perfectly reasonable and intuitive, both isolated and in "#2" (producing the number + 2 cells ⠼⠃; to be implemented in multicell output).

Roundup: this way the number characters 0-9 are used straight what they are: decimal digits. It's just we need to change our code for cell dots-2, input code "2" is needed for the digit. I think "dots-2" and "dot-2" would be OK for this, since most literature uses that cell-definition. -DePiep (talk) 09:56, 16 August 2012 (UTC)

The easiest way to enter a braille cell, if you don't know braille, is to type numbers for the dots. We do that all the time. "#2" however is hardly ever used. Why bother, when you can just enter "b" or (dots) "12"? (Esp. since "2" is not dots 1-2 for everybody.) I don't see how we gain anything by supporting bare digits, while we loose the current simplicity of the input. — kwami (talk) 20:30, 16 August 2012 (UTC)

Even more easy: if you dont know braille, is to enter "2" and expect braille for "2" in return. Simplicity is on one side only. And for ⠼⠃ no single code then, or "##2"? -DePiep (talk) 17:17, 21 August 2012 (UTC)

Entering the dots and not getting the dots is not easier, it's simply confusing. It's also unnecessary. — kwami (talk) 20:55, 21 August 2012 (UTC)

I'll leave it as it is. And no multicell shortcut to produce ⠼⠃. -DePiep (talk) 14:40, 23 August 2012 (UTC)

Text by default

split kwami post into a separate section. -DePiep (talk) 09:33, 16 August 2012 (UTC)

Our current template is for a "braille cell", and by default outputs a graphic. Could we maybe add a {{brl}} template like on WP-fr that outputs text by default? Basically, just feed into the current template and supply the type parameter so we don't need to type it out by hand? — kwami (talk) 20:49, 14 August 2012 (UTC)

Copying the code into a 2nd template (with the one change) is not a programmers friend: we'll have to maintain two templates, for each and every edit. Also old "Korean" and "Japanese" options (type=, for the colored cells) adds to the complexity.

Why not change the default to text=type" (and check all pages beforehand)? -DePiep (talk) 10:01, 16 August 2012 (UTC)

Allowing a shortcut 't' for 'text' wouldn't be too bad. I think setting it as the default would be good; we could support the graphics overtly w AWB.

Why would we need to copy the code? Couldn't we just have one call the other, setting the type to 'text'? — kwami (talk) 20:26, 16 August 2012 (UTC)

Shortcut type=t exists, but is not enough.

I asked WP:VPT. Answer: one cannot change input through a redirect (so {{braille cell}} will have be the same input as its redirect {{bcl}}). [11] -DePiep (talk)

I didn't understand the answer, so I asked again. — kwami (talk) 07:05, 17 August 2012 (UTC)

A template {{bcl}} could be a Redirect to the regular {{braille cell}}, but it can not change setttings (a redirect cannot set type=text). Alternatively, adding code to the page {{bcl}} (calling the basic template with the type parameter set to text), is undesired (bad programming), because we'd have to maintain (& always test) two code variants.

We'll set the default to type=text. As you note, before I'll do a check to prevent undesired changes. -DePiep (talk) 11:13, 17 August 2012 (UTC)

I have edited out all unspecified type pages (mostly into type=image or type=i). Now we can change the default to type=text. Is that what we want to? -DePiep (talk) 13:23, 17 August 2012 (UTC)

There's no need for either a redirect or two code variants. All we need to do is specify that type=text. — kwami (talk) 05:14, 18 August 2012 (UTC)

 Done. So:

• {{braille cell|a}} → ⠁
• {{braille cell|a|type=image|size=20px}} →

Propose new version

I propose to move to the new version, now in the sandbox. Changes (see {{braille cell/testcases}}):

• Multicell output. The lists now can have two-cell definition: [ = 6 2356, so input [ produces two cells:

{{braille cell/sandbox|[}} → ⠠⠶

Multicell input is already defined for English, French punctuation, and two Japanese definitions.

• Three or four cells output can also be defined. For technical reasons, cell 3 & 4 must be defined in a separated list. See {{braille cell/sandbox}}, look for dot-id3&4. e.g. ellipsis:

{{braille cell/sandbox|ellipsis}} → ⠄⠄⠄

• Null (whitespace) can be entered. This produces a regular whitespace, not the dots-none braille cell:

{{braille cell/sandbox|a|whitespace|b}} → ⠁ ⠃

• Not done yet: UEB, caption below, table-structure by template. -DePiep (talk) 12:14, 2 September 2012 (UTC)

 Done If problem, then let me know (how smart is that;-) ). -DePiep (talk) 00:35, 8 September 2012 (UTC)

Undone. That caused every transclusion to display twice, with a line break between. — kwami (talk) 06:30, 8 September 2012 (UTC)

Weird. Solved. -DePiep (talk) 11:04, 8 September 2012 (UTC)

help

can't ID the last assigned value in Braille's original system, which is ⠜. asked at the ref desk, but they can't ID it either. — kwami (talk) 23:57, 9 August 2012 (UTC)

accessibility for the blind

I made Albanian Braille blind-accessible here, since screen readers can't read graphics. Is there a way to do this automatically, perhaps with unicode output as the alt text, so that we can simply use graphics and yet have the article accessible to the blind? We can go through and try to do it manually, but it ain't always gonna happen. — kwami (talk) 07:23, 18 August 2012 (UTC)

If we need to repeat the graphic in font, the graphic is superfluous. I don't think WP:ACCESS can require to repeat information this way. -DePiep (talk) 09:21, 18 August 2012 (UTC)

Your edit can stay as long as we talk, but please don't propagate. My opinion is that it is a misinterpretation of WP:ACCESS and WP:WPACCESS. I think WP:ALT (for images, WP:EIS) does the job as required. Demo: image with mouse hover text (is alt=-text): ⠁. Is what a non-graphic screen sees. This is a short speedy reply (using these capitals), ask for more and I'll be here. -DePiep (talk) 18:14, 18 August 2012 (UTC)

I have no idea what you just said. There is no mouse-over.

Alt does not do the job required: It doesn't display. Text-only does not do the job required: it requires non-ubiquitous fonts. The only articles I've seen which do do the job are those which have both img and text. Maybe we could use Javascript to give readers a choice of which they wish to use? — kwami (talk) 11:51, 19 August 2012 (UTC)

The alt-text is supposed to display instead of the image when the image is not available. (I test that in my Firefox setting Tools | Options | (unmark) Load images automatically). For it shows (reconstructed): ⠁ (braille pattern dots-1) linked to the image. This is according to WP:ALT.

Alt does not do the job required: when or where is that? With me, Albanian Braille has the same effect as expected (just described).

This is even true when the userside font would miss the braille signs. The remaining alt-text is legible, still defining the image.

Adding a js -- eh, the alt=-technique as described is already there. It is a basic feature for images. I can't see how the js would help us.

-DePiep (talk) 16:21, 21 August 2012 (UTC)

A partially sighted user stated that alt does not work if you're enlarging the screen. I don't know the details. — kwami (talk) 20:16, 23 August 2012 (UTC)

alt is not related to screen zoom size, AFAIK. How does the template {{braille cell}} not conform to WP:ALT? -DePiep (talk) 23:21, 23 August 2012 (UTC)

That's never been the point. The problem is that ALT does not provide sufficient accessibility. — kwami (talk) 00:41, 24 August 2012 (UTC)

Then, what is missing? since screen readers can't read graphics you wrote first here. That is true, of course, but what is missing in the ALT-procedure? Is there some other WP:ACCESS guideline I looked over? -DePiep (talk) 14:29, 24 August 2012 (UTC)

Not screen readers, sorry. Enlarging the print so that its legible. The alt procedure doesn't do anything in such situations. — kwami (talk) 18:29, 24 August 2012 (UTC)

So you refer to the situation: view (true print maybe) is illegible, but when enlarged (zoomed ++) it becomes accessible? How is that a blind-accessible issue? -DePiep (talk) 21:55, 25 August 2012 (UTC)

I don't understand the first sentence. It's a blind issue because that's what the legally blind often do to read an article. — kwami (talk) 23:30, 25 August 2012 (UTC)

error

Entering "?" in the template once produced ⠢ (the French ?), but now produces ⠦ (the English ?). However, articles such as Arabic Braille were written when it had the old value, and the change in coding introduced an error into that article without it being edited and reviewable. I suggest we not allow "?" or "." as inputs, since they're so variable. We'll want any articles that use them to produce errors so they can be verified. — kwami (talk) 09:35, 20 November 2013 (UTC)

Ok. I think that's been around a long time. I haven't seen any changes that would effect this, so English punctuation seems to have been the default in the logic for quite a while now. VanIsaac_{WS Vex}^contribs 09:56, 20 November 2013 (UTC)

Yes, but there could be other early uses of it that have gone unnoticed. — kwami (talk) 10:11, 20 November 2013 (UTC)

Link option?

What about a link option? Adding, say, "type=link" to get a link to the article on that cell pattern. That way it would be easy to add links to the tables w AWB. — kwami (talk) 14:02, 30 November 2013 (UTC)

So I've tried to program something in quick and dirty: {{bc|type=link|125}} gives us Braille pattern dots-125 - just the plain article name, and {{bc|type=textlink|125}} gives ⠓ - the unicode character as a link to the article. That work for now? VanIsaac_{WS Vex}^contribs 17:15, 30 November 2013 (UTC)

Yes, thanks. I'll try it out at Georgian Braille. — kwami (talk) 23:54, 30 November 2013 (UTC)

Korean error

Here someone change the language of the template to Korean, but the M came out wrong, so I reverted. — kwami (talk) 20:18, 2 December 2013 (UTC)

8-dot default

The 8-dot default is an image, while the 6-dot default is text. They should be the same. — kwami (talk) 20:20, 2 January 2014 (UTC)

Default background should not be fixed color

The documentation says the default background color is #f4f4f4. But this isn't really readable if the text color is white, which can happen with dark mode stylesheets for Wikipedia. Perhaps no default background color should be specified at all. - Gilgamesh (talk) 04:36, 13 July 2024 (UTC)

It looks like the background color is dark in dark mode, but transparent-background versions of the dot patterns have been uploaded. This means that in dark mode, the dots are black on a dark grey background, and are hard to read. -- Beland (talk) 09:36, 26 November 2024 (UTC)