[sword-devel] Quasi-internationalized versions of LcdBible available
Lynn Allan
sword-devel@crosswire.org
Sun, 14 Dec 2003 08:10:19 -0700
This is a multi-part message in MIME format.
------=_NextPart_000_0008_01C3C219.B7073660
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
[sword-devel] Quasi-internationalized versions of LcdBible available =
(spanish-rv, french-lsg, german-lut)Hi Sword-devel'ers,
>> How are you actually doing the i18n? From this end it sounds like =
you=20
>> might actually be maintaining separate codebases or something rather=20
>> than using different resource files to swap strings. Maybe I just=20
>> missed something in an earlier post.
The quasi-internationalized versions of the LcdBible software use a very =
simple approach to accomplishing an "80/20" degree of =
internationalization. The "plug-in subset" of CanonVersifier.inl =
(replacement for Canon.h and VerseKey) has #defines that distinct =
Microsoft Visual C++ projects control:
#define TRANS_NT_SPANISH=3D1
#define TRANS_NT_GERMAN=3D1
#define TRANS_NT_FRENCH=3D1
In the LcdBibleDlg.cpp code, these same #defines control what module is =
opened, and what phrase is used for the "Search Phrase" text.
#if TRANS_NT_GERMAN =3D=3D 1 =20
m_pRawVerse =3D new RawVerse("modules\\texts\\rawtext\\GERLUT", =
O_RDONLY);
m_searchPhraseButton.SetWindowText("Suche Nach:");
#elif TRANS_NT_SPANISH =3D=3D 1 =20
m_pRawVerse =3D new RawVerse("modules\\texts\\rawtext\\SPARV", =
O_RDONLY);
m_searchPhraseButton.SetWindowText("B=FAsqueda Para:");
#elif TRANS_NT_FRENCH =3D=3D 1 =20
m_pRawVerse =3D new RawVerse("modules\\texts\\rawtext\\FRELSG", =
O_RDONLY);
m_searchPhraseButton.SetWindowText("Recherche De:");
#elif TRANS_NT_FINNISH =3D=3D 1 =20
m_pRawVerse =3D new RawVerse("modules\\texts\\rawtext\\xxxxx", =
O_RDONLY);
#elif TRANS_NT_GREEK =3D=3D 1 =20
m_pRawVerse =3D new RawVerse("modules\\texts\\rawtext\\xxxxx", =
O_RDONLY);
#elif TRANS_NT_ITALIAN =3D=3D 1 =20
m_pRawVerse =3D new RawVerse("modules\\texts\\rawtext\\xxxxx", =
O_RDONLY);
#elif TRANS_NT_ICELAND =3D=3D 1 =20
m_pRawVerse =3D new RawVerse("modules\\texts\\rawtext\\xxxxx", =
O_RDONLY);
#else=20
m_pRawVerse =3D new RawVerse("modules\\texts\\rawtext\\WEB", =
O_RDONLY);
#endif
That's pretty much it. The above probably doesn't scale well, but =
sufficed for quick/dirty 80/20 implementation to meet the Friday COB =
milestone.
>> If you're using Sword, there are some i18n routines built in I =
believe.=20
>> Aside from that, if i18n/l10n are real goals, you should consider=20
>> using ICU, since its features are much more robust than those in =
Sword.=20
>> You'll definitely want to consider ICU for InVerse, since it has some =
>> very nice international calender data (localized weekdays & months,=20
>> different religious calendars, local holidays, etc.).
A primary objective of LcdBible is a very small download. Each of the =
self-contained, statically linked LcdBible.exe for the above is only =
32kb. I can't imagine that being possible with the full sword-api and/or =
use of icu. (See preliminary requirements / design document)
http://prdownloads.sourceforge.net/lcdbible/LcdBibleReqDesign.doc
A peripheral object of LcdBible is to identify and implement a radically =
simplified "plug-in subset" of the sword-api. That is taking place based =
on experience gained with LcdBible. LcdBible uses the radically =
simplified CanonVersifier and simplified RawText classes to fetch =
verses. I will eventually be proposing parent/contained classes for =
VerseKey and RawText to facilitate other apps for which this might be =
advantageous. The actually logic should be radically simpler for a sword =
newbie volunteer to follow, as applicable.
(This could be accomplished with using something like
#define PLUGIN_SUBSET
but this would adversely impact readability and )
Another peripheral objective is to implement actual .dll and .lib logic =
to facilitate "plug-ins". Experience with LcdBible seems to indicate =
this should be feasible. Once someone has "paid the price" of the 8.5meg =
"Starter-Set", subsequent plug-ins should be very small, and be on the =
order of a "why not" decision. Or the starter-set could include the =
smaller plug-ins???=20
Another peripheral objective of LcdBible is to significally improve =
developer rebuild delays. Use of CanonVersifier.inl allows precompiled =
headers to work ok, which drastically improves rebuild times.=20
<An aside: Canon.h has defined arrays for some no-doubt good reasons, =
but this also creates problems for data abstraction and data hiding)>
>> I only wrestled with uncompressed Bible texts
>> * The installation routine words aren't translated.
>> * The titlebar isn't translated
>> * I'm not clear if all these use the same versification, but assumed =
this
>> was the case
> If they're Sword modules, they do, but in reality they don't. (French =
> versification being famously distinct from English.)
I don't understand the above, but, for now, not too concerned. 80/20.
<For those not clear on my use of 80/20, this derives from the Italian =
economist Pareto for achieving 80% of the advantages with 20% of the =
effort>
Sharing the reason for the season,
http://learningcards.eeworks.org/EeCard01.html
- Lynn A.
l.allan@att.net
------=_NextPart_000_0008_01C3C219.B7073660
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>[sword-devel] Quasi-internationalized versions of =
LcdBible available (spanish-rv, french-lsg, german-lut)</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252"><BASE=20
href=3Dhttp://www.crosswire.org/pipermail/sword-devel/2003-December/01994=
6.html><LINK=20
href=3D"index.html" rel=3DIndex><LINK =
href=3D"mailto:sword-devel%40crosswire.org"=20
rel=3Dmade>
<META content=3Dindex,nofollow name=3Drobots><LINK href=3D"019943.html"=20
rel=3DPrevious><LINK href=3D"019942.html" rel=3DNext>
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi Sword-devel'ers,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>>> How=20
are you actually doing the i18n? From this end it sounds like you=20
<BR>>> might actually be maintaining separate codebases or =
something=20
rather <BR>>> than using different resource files to swap =
strings. =20
Maybe I just <BR>>> missed something in an earlier =
post.</FONT><BR><BR>The=20
quasi-internationalized versions of the LcdBible software use a very =
simple=20
approach to accomplishing an "80/20" degree of =
internationalization.=20
The "plug-in subset" of CanonVersifier.inl (replacement for Canon.h and=20
VerseKey) has #defines that distinct Microsoft Visual C++ projects=20
control:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>#define TRANS_NT_SPANISH=3D1
<DIV><FONT face=3DArial size=3D2>#define TRANS_NT_GERMAN=3D1
<DIV><FONT face=3DArial size=3D2>#define =
TRANS_NT_FRENCH=3D1</FONT></DIV>
<DIV> </DIV>
<DIV>In the LcdBibleDlg.cpp code, these same #defines control what =
module is=20
opened, and what phrase is used for the "Search Phrase" text.</DIV>
<DIV>#if TRANS_NT_GERMAN =3D=3D 1 <BR> m_pRawVerse =3D new=20
RawVerse("modules\\texts\\rawtext\\GERLUT", O_RDONLY);<BR> =20
m_searchPhraseButton.SetWindowText("Suche Nach:");<BR>#elif =
TRANS_NT_SPANISH =3D=3D=20
1 <BR> m_pRawVerse =3D new =
RawVerse("modules\\texts\\rawtext\\SPARV",=20
O_RDONLY);<BR> m_searchPhraseButton.SetWindowText("B=FAsqueda=20
Para:");<BR>#elif TRANS_NT_FRENCH =3D=3D 1 <BR> m_pRawVerse =
=3D new=20
RawVerse("modules\\texts\\rawtext\\FRELSG", O_RDONLY);<BR> =20
m_searchPhraseButton.SetWindowText("Recherche De:");<BR>#elif =
TRANS_NT_FINNISH=20
=3D=3D 1 <BR> m_pRawVerse =3D new=20
RawVerse("modules\\texts\\rawtext\\xxxxx", O_RDONLY);<BR>#elif =
TRANS_NT_GREEK =3D=3D=20
1 <BR> m_pRawVerse =3D new =
RawVerse("modules\\texts\\rawtext\\xxxxx",=20
O_RDONLY);<BR>#elif TRANS_NT_ITALIAN =3D=3D 1 <BR> =
m_pRawVerse =3D new=20
RawVerse("modules\\texts\\rawtext\\xxxxx", O_RDONLY);<BR>#elif =
TRANS_NT_ICELAND=20
=3D=3D 1 <BR> m_pRawVerse =3D new=20
RawVerse("modules\\texts\\rawtext\\xxxxx", O_RDONLY);<BR>#else =
<BR> =20
m_pRawVerse =3D new RawVerse("modules\\texts\\rawtext\\WEB",=20
O_RDONLY);<BR>#endif</DIV>
<DIV> </DIV>
<DIV>That's pretty much it. The above probably doesn't scale well, but =
sufficed=20
for quick/dirty 80/20 implementation to meet the Friday COB=20
milestone.</DIV></FONT></DIV></FONT></DIV></FONT><FONT face=3DArial=20
size=3D2></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>>> If you're using Sword, there are some i18n routines built =
in I=20
believe. <BR>>> Aside from that, if i18n/l10n are real goals, =
you=20
should consider <BR>>> using ICU, since its features are much more =
robust=20
than those in Sword. <BR>>> You'll definitely want to =
consider ICU=20
for InVerse, since it has some <BR>>> very nice international =
calender=20
data (localized weekdays & months, <BR>>> different religious=20
calendars, local holidays, etc.).</DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>A primary objective of LcdBible is a=20
very small download. Each of the self-contained, statically =
linked=20
LcdBible.exe for the above is only 32kb. I can't imagine that being =
possible with the full sword-api and/or use of icu. (See preliminary=20
requirements / design document)</FONT></DIV>
<DIV><A=20
href=3D"http://prdownloads.sourceforge.net/lcdbible/LcdBibleReqDesign.doc=
">http://prdownloads.sourceforge.net/lcdbible/LcdBibleReqDesign.doc</A></=
DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>A peripheral object of LcdBible is to =
identify and=20
implement a radically simplified "plug-in subset" of the sword-api. That =
is=20
taking place based on experience gained with LcdBible. LcdBible uses the =
radically simplified CanonVersifier and simplified RawText classes to =
fetch=20
verses. I will eventually be proposing parent/contained classes for =
VerseKey and RawText to facilitate other apps for which this might be=20
advantageous. The actually logic should be radically simpler for a =
sword=20
newbie volunteer to follow, as applicable.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>(This could be accomplished with using =
something=20
like</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>#define PLUGIN_SUBSET</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>but this would adversely impact =
readability and=20
)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Another peripheral objective is to =
implement actual=20
.dll and .lib logic to facilitate "plug-ins". Experience with LcdBible =
seems to=20
indicate this should be feasible. Once someone has "paid the price" of =
the=20
8.5meg "Starter-Set", subsequent plug-ins should be very small, and =
be on=20
the order of a "why not" decision. Or the starter-set could include =
the=20
smaller plug-ins??? </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Another peripheral objective of =
LcdBible is to=20
significally improve developer rebuild delays. Use of CanonVersifier.inl =
allows=20
precompiled headers to work ok, which drastically improves rebuild =
times.=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><An aside: Canon.h has defined =
arrays for some=20
no-doubt good reasons, but this also creates problems for data =
abstraction=20
and data hiding)></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
face=3DArial size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT =
face=3DArial=20
size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
size=3D2></FONT><BR><I>>> I only wrestled with uncompressed =
Bible=20
texts<BR></I>>><I> * The installation routine words aren't=20
translated.<BR></I>>><I> * The titlebar isn't=20
translated<BR></I>>><I> * I'm not clear if all these use the same=20
versification, but assumed this<BR></I>>><I> was the =
case<BR></I><BR>>=20
If they're Sword modules, they do, but in reality they don't. =
(French=20
<BR>> versification being famously distinct from English.)<BR></DIV>
<DIV><FONT face=3DArial size=3D2>I don't understand the above, but, for =
now, not too=20
concerned. 80/20.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><For those not clear on my use of =
80/20, this=20
derives from the Italian economist Pareto for achieving 80% of the=20
advantages with 20% of the effort></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Sharing the reason for the =
season,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://learningcards.eeworks.org/EeCard01.html">http://learningca=
rds.eeworks.org/EeCard01.html</A></FONT></DIV></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>- Lynn A.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"mailto:l.allan@att.net">l.allan@att.net</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV></BODY></HTML>
------=_NextPart_000_0008_01C3C219.B7073660--