[jsword-devel] I18N
Aleksander Rozman - Andy
jsword-devel@crosswire.org
Tue, 30 Dec 2003 13:22:06 +0100
At 12/30/2003, you wrote:
>Hey Andy,
> Appreciate your comments, and maybe it's a language barrier, but
> it seems to me like you are making hard statements in a derogatory manner
> to provoke.
>
> Assuming it's a language barrier, I'll try to exemplify the
> correct way to make statements:
>
> I don't feel it is a good rule to state that "no variable should
> be public and directly accesable [sic], by outer entities". For example,
> you can find the entire Java library suite dependent on public
> variables. Just to cite a few:
>
>JFrame.EXIT_ON_CLOSE
>Frame.DEFAULT_CURSOR
>Container.TOP_ALIGNMENT
>System.out;
Yes. As I said before, things should be like that, not that they are. In
java we use static variables mainly for settings, not for containg data,
that could also be available othervise (Java has special classes for I18N
and many other ways to store I18N strings).
> In work with Bjarne Stroustrup, a few years back, on a 'property'
> mechanism for use in C++ semantics, we aimed specifically to let objects
> be available publicly, and to let them provide hidden setters and
> getters, if they desired, but the default action was to merely let the
> proxy object be 'set/get'. In my humble understanding of his motives for
> publishing such a mechanism it seems to me that he desired to enable
> people to make objects public, and specifically provide programmers a
> mechanism to supply a hidden getter/setter if required.
Yeah we programers usally do this in that way. We create public variables,
with get/set methods. If we would want to create real OOP applications, we
would have to make all variables private. Sometimes is just easier doing it
this way....
> To conclude, I believe your programming books claim, in general,
> that method setter/getter calls are a good idea in most cases, which does
> not preclude that in some cases, there are better ways to implement.
Sometimes is easier not do 100% OOP application... I usually don't do
private varaibles, but I also almost never use static variables (except for
settings, and Singelton Patterns)...
> Hope this helps.
>
> -Troy.
>
>
>
>Aleksander Rozman - Andy wrote:
>>At 12/30/2003, you wrote:
>>
>>>Andy - this is well worth reading - JSword does something very similar
>>>in looking up strings.
>>>
>>>The one difference is that where Sword uses "const char*" as the type to
>>>look up JSword has a "static final Msg" which lets us add type safety in
>>>some places.
>>
>>const char* is quite allowed in C, while static final should be used in
>>Java, just for settings that should be applied to methods in class.
>>
>>>So JSword code looks like this:
>>>
>>> throw new BlahException(Msg.WRITE_FAIL);
>>
>>Every thing can thrtow exception. If we read from resource file we get
>>null value then we can also throw Exception
>>
>>>Note you can't throw unless you take note of I18N. This is not a system
>>>for sloppy programmers.
>>>And in the local Msg class
>>>
>>> static final Msg WRITE_FAIL = new Msg("Failed to write");
>>
>>OOP (Object Orient Programmings) principles, state that no variable
>>should be public and directly accesable, by outer entities. All varaibles
>>should be private in class and accessible by setter/gettter methods. We
>>programers usually make variables public so that they can be accessible
>>from outer entities, static final variables shouldn't even be used...
>>
>>
>>>And in the French resource file:
>>>
>>> Failed to read=N'ecrire pas
>>>
>>>(or something)
>>>
>>>Hope this helps.
>>>
>>>Joe.
>>>
>>>Troy A. Griffitts wrote:
>>>
>>>>Hey guys. I also had a tough time deciding how to handle i18n in the
>>>>windows frontend. As well, we are building an i18n mechanism for our
>>>>website. Here are some of my thoughts.
>>>> I agree 100% that I hate keeping string files up to date. I hate
>>>> looking at DEFINE_TOKENS instead of the actual string, and I hate
>>>> going somewhere to have to change the string other than right where
>>>> I'm at in the code.
>>>> Here was my solution in the Windows client: Since Borland's VCL
>>>> GUI classes provide programmatic methods to change all the 'Caption'
>>>> or 'Text' properties of a control, we have 1 function called
>>>> i12ize(const char *lang), which is where all the stupid monolithic
>>>> calls to EVERY control exist to change it's text. There are also
>>>> classes in the SWORD engine called SWLocale and LocaleMgr which manage
>>>> locales and do simple lookups from a basic .conf file formatted like:
>>>>My English Text=My Alternate Language Text
>>>>Here are excerpts from the code:
>>>>____________________
>>>>#define _tr(text) LocaleMgr::systemLocaleMgr.translate(text)
>>>>void TForm1::i12ize(const char *lang) {
>>>> LocaleMgr::systemLocaleMgr.setDefaultLocaleName(lang);
>>>> File1->Caption = _tr("&File");
>>>> SaveLayout1->Caption = _tr("S&ave Layout");
>>>> Print1->Caption = _tr("&Print...");
>>>> ...
>>>>____________________
>>>>translate() looks up the English phrase in the current locale.conf
>>>>file, and returns the translation, if it finds it; otherwise, it just
>>>>returns back the English phrase.
>>>>Benefits:
>>>>o You can code normally, without worrying about i18n.
>>>>o Worst case is the English will show up on the control
>>>>o And my favourite part: You can declare, "This is an open source
>>>>project! If you want your language supported, then test it, look for
>>>>english strings, and update your lang.conf file!"
>>>>Those lines should probably be changed to:
>>>>- File1->Caption = _tr("&File");
>>>>+ File1->Caption = _tr(File1->Caption);
>>>>And better yet a programmatic walk of the control tree, instead of
>>>>naming each control individually, would be IDEAL.
>>>>____
>>>>For the web interface, we're working on a taglib that adds
>>>>functionality like:
>>>><table>
>>>><tr><td><t>My text</t></td></tr>
>>>></table>
>>>>(Example above, set in a table to just show that it's not extremely
>>>>intrusive)
>>>>The <t> tag does a lookup and replace of the string in much the same
>>>>way as LocaleMgr. It will also allow someone to log in as an admin,
>>>>set a session variable admin to true, then a link at the bottom of each
>>>>page will appear that says: Administrate I18n
>>>>While browsing the website, if an administrator sees an English word,
>>>>they may click this link, and be taken to a page where they are
>>>>presented with all the <t>English Text Strings</t> and the existing
>>>>translations, and are able to update any that are wrong or missing.
>>>>Benefits: It only has one evil tag addition, <t> around all text, and
>>>>still allows me to make the coveted Open Source Declaration mentioned above.
>>>> :)
>>>>Hope this, at least, gives some ideas to throw around from someone
>>>>who's struggling with the same issues.
>>>> -Troy.
>>>>
>>>>
>>>>Joe Walker wrote:
>>>>
>>>>>
>>>>>JSword used to use a method very similar to yours, and I found that
>>>>>the message file was constantly getting out of date with respect to the source.
>>>>>There were 3 problems:
>>>>>- editing properties files was a hassle
>>>>>- unused messages would not be purged
>>>>>- lazy developers (me!) would add an i18n key thinking "i'll add it to
>>>>>the message file later" and never do it.
>>>>>
>>>>>The Msg system solves these problems by making the I18N type-safe -
>>>>>Exceptions take a Msg and not a String and so on.
>>>>>
>>>>>You can now navigate to the message with a single key press in any
>>>>>decent IDE (in eclipse I just press F3)
>>>>>You can detect if the message is used without lengthy search
>>>>>procedures with your IDE (ctrl+shift+g in eclipse)
>>>>>The english developer can ignore message files completely because the
>>>>>messages are in the source
>>>>>JSword can sill be internationalized simply by adding message files
>>>>>
>>>>>To clear up some of the points you made:
>>>>>Does this scheme waste space?
>>>>>We use extra static space for a few objects that wrap strings. Only
>>>>>one copy of MsgBase is needed, and the strings themselves (the things
>>>>>that take up the real space) would exist anyway.
>>>>>So yes this does waste some space, but I think that is a reasonable
>>>>>price to pay.
>>>>>
>>>>>Joe.
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>jsword-devel mailing list
>>>>>jsword-devel@crosswire.org
>>>>>http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>>
>>>>
>>>>_______________________________________________
>>>>jsword-devel mailing list
>>>>jsword-devel@crosswire.org
>>>>http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>
>>>
>>>
>>>_______________________________________________
>>>jsword-devel mailing list
>>>jsword-devel@crosswire.org
>>>http://www.crosswire.org/mailman/listinfo/jsword-devel
>>
>>**************************************************************************
>>* Aleksander Rozman - Andy * Fandoms: E2:EA, SAABer, Trekkie, Earthie *
>>* andy@kksonline.com * Sentinel, BH 90210, True's Trooper, *
>>* andy@atechnet.dhs.org * Heller's Angel, Questie, Legacy, PO5, *
>>* Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender *
>>* ICQ-UIC: 4911125 *********************************************
>>* PGP key available * http://www.atechnet.dhs.org/~andy/ *
>>**************************************************************************
>>_______________________________________________
>>jsword-devel mailing list
>>jsword-devel@crosswire.org
>>http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>_______________________________________________
>jsword-devel mailing list
>jsword-devel@crosswire.org
>http://www.crosswire.org/mailman/listinfo/jsword-devel
**************************************************************************
* Aleksander Rozman - Andy * Fandoms: E2:EA, SAABer, Trekkie, Earthie *
* andy@kksonline.com * Sentinel, BH 90210, True's Trooper, *
* andy@atechnet.dhs.org * Heller's Angel, Questie, Legacy, PO5, *
* Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender *
* ICQ-UIC: 4911125 *********************************************
* PGP key available * http://www.atechnet.dhs.org/~andy/ *
**************************************************************************