[jsword-devel] I18N
Joe Walker
jsword-devel@crosswire.org
Tue, 30 Dec 2003 09:51:06 +0000
Hi,
Java considers the package to be the primary protection mechanism rather
than the class as many other languages do. That is why by default a
variable is package protected rather than private.
Normally I do use private for variables, but in this case it clearly
wouldn't work! So I use package (default).
Joe.
Troy A. Griffitts 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;
>
> 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.
>
> 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.
>
> 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