As a one time Bible translator and present adviser on translation, I
notice that there is a linguistic clash going on here. Languages not
only have phoneme level meaning (spelling) and what is normally called
"grammar" (word order and sentence structure) but also higher level
grammar items - paragraphing is the specific one noted here but there
are others such as introductions, time identification, etc. Osis is
intended to catch all the semantic (grammar and other meaningful
communication) making it appropriately. Presentation is considered
"other" issues.
Bible translators operate in the semantic field, but they also work on
the literacy side. Here presentation is a large part of communication
the meaning. Paragraphing is a semantic concept which all agree is
important (see the pilcrows in the KJV project) but the presentation is
important because the presentation may either enhance or confuse the
meaning - try for example to read a Bible Greek manuscript (or Hebrew)
where paragraphing or even "wording" does not exist.
However, presentation is also media specific, what works for
paragraphing for paper does not necessarily work for desktop computers
or for smart phones. It would be good to ask some translators to
experiment with smart phones to see in those situations what
presentation will work. This part of the discussions sounds like it
needs more research. My understanding of Bible translation work is that
experimentation is part of the process.
On the other hand, if experience says a particular language should
prohibit/demand certain presentation characteristics then those should
be programmable. The key for OSIS is that those characteristics should
be semantic and described as such, not in terms of a particular
presentation request, though that may end up being the desired
presentation of that semantic reality.
in Christ,
Pr Arthur Bolstad
isaiah5511.shutterfly.com
On 4/12/2013 10:27 PM, John Austin wrote:
On 04/13/2013 07:34 AM, Greg Hellings wrote:
On Fri, Apr 12, 2013 at 4:37 PM, Matěj Cepl <[email protected]
<mailto:[email protected]>> wrote:
My point was that documents are more valuable and more difficult to
change than programs. So we should orient on perfecting documents
and change programs if necessary. And yes, possibility of using
stylesheets would be awesome, but that isn't necessarily the point.
The point is
1) His publishers want to control indents
2) Sword doesn't want to give this control through XML
3) Sword does not support stylesheet mechanisms for giving module
creators this control.
Presently, there are some half-way workarounds that are only effective
in some places.
1) Not use OSIS XML but instead use ThML. But this only functions in
HTML-based applications
2) Use the forms of OSIS XML that are mentioned earlier, which are
non-ideal. But this only works in xulsword
3) Change the applications, which is an unfeasible level of effort, as
the number of applications could increase without bound.
This problem has been hashed out many times. There seems to be no
satisfactory method to give publishers the type of control they want. We
can't specify CSS styles, since only some of our applications can parse
and utilize CSS. We can't specify RTF for the same reason. We can't
allow XSL because only JSword uses XSLT on the OSIS whereas Sword uses a
stream text processor that roughly resembles SAX which allows it to work
marvelously on low-memory devices with great success.
In theory the ideal way for us to handle XML sources would be to allow
each application or device to specify an XSLT which is combined with one
from the module to prevent certain output that the target device cannot
handle. But, in practice, this doesn't work very well as not every
programming environment has access to XSLT libraries and some devices
can't handle the large memory overhead needed to load in an XML file
that is several MB (like the one for the KJV), transform it, and write
it back out in an efficient manner.
So we're stuck in an unenviable position of being forced to either
suggest a user select one of these partial hacks or tell people that we
can't honor their request for control over the formatting.
But the situation is more hopeful if we keep focus on the original
subject: indents and line breaks.
Wouldn't a good solution be this:
1) Agree that all translator dictated content is important and that it
should be stored in the OSIS file. This includes milestone indents
when hand placed by translators, since their purpose is not style,
structure, or presentation, but rather part of making the text
understandable and readable.
2) Agree that there will always be natural limitations regarding what
content Sword is able to render. Sword can not attempt to render every
conceivable content. Sword should attempt to choose wisely and
carefully what practical content it is expected to support.
3) Go ahead and add a line or two of code to render the milestone
indent content as an indent. This adheres to Sword's purposes of
safekeeping Bible translation content, and supporting ministry needs.
I believe, according to most of what I've read from people during this
discussion, that it only requires a rethinking to accept translator
placed indents as content- to see that this is a very nice solution.
--Greg
Blessings,
Matěj
--
http://www.ceplovi.cz/matej/, Jabber: [email protected]
<mailto:[email protected]>
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
_______________________________________________
sword-devel mailing list: [email protected]
<mailto:[email protected]>
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
