I agree that removing the -i18n option from the wiki is the fastest way to resolve the issue.
Larry On 9/13/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > 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 > -- http://amusingprogrammer.blogspot.com/ _______________________________________________ jump-users mailing list [email protected] http://lists.refractions.net/mailman/listinfo/jump-users
