[sword-devel] Rendering added words for languages that don't use italics?

[Greg Hellings]

On Tue, Apr 19, 2011 at 10:24 AM, Peter von Kaehne <refdoc at gmx.net> wrote:
> The <i> interpretation happens very late in our chain - at rendering filter level. And I would think it is probably a wrong
> decision. It would be trivial to change that to <em> which in turn might be rendered more likely in an appropriate emphasis of
> whatever sort in scripts which do not do italics.
>

<i> is supposed to be back and in full force with HTML5, no longer
carrying the "emphasis" idea.  <em> is still present to mean emphasis.
 Use of <em> by us for this indication would be incorrect, as we are
not trying to emphasize the words, but rather indicate they are a
translation change. A more appropriate method would be <span
class="transChange">word</span> and then let the translation choose
how it wants this represented in an HTML-based display. Which pretty
much sums up everywhere except BibleCS.

> Wrt CSS - I do not want to reopen the debate. But at the core of this particular problem is a fairly arbitrary set of conventions
> which presumably vary wildly across cultures - and even in our own language. The KJV and some related Bibles "tag"
> translation additions by packing them into []. Others use italics. We do not know what Chinese, Mongolians, Arabs use.
> Maybe they ignore the issue, maybe they use pink colouring for the fonts.
>

KJVs used italics. Some English translations use [word]. Some use
⌊word⌋. Some ignore the issue completely.  I think we're not dealing
with a language-level problem here but a translation-level problem.
Some translators recognize that they are required to provide multiple
words in some cases for the target language and combine multiple
source words. And they realize that the average reader will only be
confused by "Well the word 'is' does not really appear in the
original, so maybe this meaning is completely wrong," because the
average reader doesn't know that it was common in the source language
to omit the word 'is' and other equivalent scenarios.

This issue is really a per-module issue and not a per-language or
per-frontend issue.

> This could therefore be seen as a style issue, as all these issues could be rendered successfully (as long as the render
> engines understand the directives) at that level - adding a [ via "before" directive, changing font colour or indeed shifting to
> italics.
>
> Alternatively - and we have discussed this in another place - there is also a need for some locale dependent rendering of
> references, and this matter would be somewhat related. Instead of css styling the one before last step in the filters could
> presumably read and apply loalised rendering info ([..], <span style="font-color:pink"> or <i> tags) for any of these issues -
> i.e. by using the relevant set of alternatives in any of the issues where we want a localised output. This would then work
> across the board of libsword derived frontends (or not).
>
> Wrt implementation, if the <em> tag would do the job across scripts - and this would be a worthwhile project for someone not
> too skilled - then this woudl be all we wanted. And it would be a simple implementation.

I think choosing a presentation markup, like <em>, is a terrible idea.
It completely leaves out your own hypothetical "What if they choose to
use light pink" scenario and forces everyone to go with whatever <em>
might do to their script, including not appear at all, cause those
words to be read more loudly or forcefully or cause extra markers for
emphasis to be added or cause new words in a language to be added,
etc. Generally the purpose of denoting <transChange> is to actually do
the exact opposite - deemphasize the word as, "This was not in the
original language, so treat it with caution."

--Greg