mhm.. it sounds nice, but i do not really understand where/how to
implement and the consequences.
But as a side note: i think it took a couple of months to make every
english string international - but maybe now it would be faster as we
have already the i18n.get which needs to be replaced.
what concerns the keys: a nice idea, but a plus of the current version
is, that you really can read the original string. (but this is no
objection against using keys)
finally Larry i see that you meant something else with the menu names.
I tested a version from 21st of August that worked, while the version
from 2nd of September did not work anymore.
I also recognized, that the tool-tips that show why a menu function is
inactive are all in english and not in german. And i am quite sure that
we translated them.
probably we really should skip the -18n option. Or at least not
publicize their use. (because removing implemented functions is not a
nice thing in terms of consistency)
stefan
Larry Becker schrieb:
Hi Paul,
I kind of like your PluginMenuItem getPlugin method idea.
While the MenuNames class is imperfect, I do think some kind of
centralized control of core menus is a good thing. I don't think we
need to support changing languages while OJ is running.
regards,
Larry
On 9/13/07, Paul Austin <[EMAIL PROTECTED]> wrote:
Hi Guys,
I haven't had time to follow the thread but I have a couple of comments
on I18N and menus.
The plugi-ins that I have just released replace existing menu items and
tool bars with new ones with extended functionality. To do this I have
to find the I18N name of the menu item and then loop through the menu to
find it. Also I need to do this if I want to say insert a new menu item
after another menu item. What would be nice is if we has a
PluginMenuItem subclass of MenuItem that you would pass in an Plugin
instance. You could then find the menu item by using the getPlugin
method on these menu items.
Another point is the current use of the MenuNames constants as I18N
values. I would as someone else suggested prefer a MenuKeys class where
the constants are keys into the I18N property file. Then when you create
a menu you would use an I18NMenuItem with this key, the menu item would
then call the I18N code each time it needs to display the name and if
the language was changed it would automatically pick up this new value.
The other option is to have an I18NString class which when toString()
was called would return a String in the current language. I actually
quite like this option as you can use these anywhere that an Object
parameter is expected and toString() was used to get a string value.
Paul
_______________________________________________
jump-users mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jump-users
_______________________________________________
jump-users mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jump-users
