From: Brett L. <wak...@ea...> - 2005-11-30 22:28:09
|
See my reply to John in which I reference that same tutorial. ;-) While I don't (yet) want to completely internationalize/localize the code, it is good to be aware of how Java approaches this and make a future move a bit less cumbersome. Also, regardless of the implementation, my bigger concern is that maintaining a help system that is intertwined with the code is excessively cumbersome and ought to be avoided by everything but the earliest stages of development. ---Brett. -----Original Message----- From: ia...@co... Sent: Nov 30, 2005 5:02 PM To: rai...@li... Subject: [Rails-devel] Re: HELP >> Subject: RE: [Rails-devel] Help >> >> I just had a chance to look at the help system a little more in-depth. >> >> >At some point we're going to want to separate the text strings from the code. >Perhaps we should generate a global help xml file to hold the text, or maybe a >help directory to hold multiple files, and then also have a game->specific help file for including any game-specific help information. You need to read up on internationalization (aka I18N) and localization (aka L10N). Basically your code ends up referring to property names, which are then looked up in property files for the actual text. Different versions of the props file(s) are provided for each locale, and the user's settings determine which one is used. ISTR the tutorial trail on Suns's Java website explaining the process covered it very nicely, and didn't take long to read. I internationalised a small app in about couple of hours, including reading the tutorial. There's also an Eclipse wizard which helps configure it all for you. I'd advise having a small number of files, probably only one for the base application, rather than one per package (which is the alternative). Also make sure you use Format strings where appropriate so that you can cope with parameters (e.g. company name, currency refs, etc) being in different places in the text in different languages. Iain. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Brett L. <wak...@ea...> - 2005-12-01 00:07:46
|
I understand, and to some extent agree. I think it's sufficient to provide help on the current round. Context-sensitive help is nice, but really not necessary. ---Brett. -----Original Message----- From: Erik Vos <eri...@hc...> Sent: Nov 30, 2005 6:30 PM To: rai...@li... Subject: RE: [Rails-devel] Re: HELP At the moment, the game and game-state dependency of the help texts concerns me a lot more than internationalization. At one point I thought about creating a HTML file per game step, each one being a template to be run through a formatter to replace variables by real data (such as OR number, player/company turn etc.). This could (of course) be a file per language. But there seems to be too much variability between games to make this an easy approach. We would end up with a file per game, game step and language, and even then we would need some trickery to handle phase-dependent info (such as that mentioning the option to buy privates in 1830 should only show up in the green phase). Perhaps my original goal to exactly describe all currently available options at every point in time is too optimistic. Anyway, the only point I was trying to make so far is, that the help displayed by the UI must be provided somehow by the currently active Round subclass. That 'somehow' now consists of full HTML text, but it might well become some language-independent Help class, or just an array of resource bundle keys, that would be turned into language-dependent HTML by the GUI (possibly a different language per player). Just thinking aloud. Erik. > -----Original Message----- > From: rai...@li... > [mailto:rai...@li...] On Behalf Of > John A. Tamplin > Sent: 30 November 2005 23:36 > To: rai...@li... > Subject: Re: [Rails-devel] Re: HELP > > On Wed, 30 Nov 2005, Brett Lentz wrote: > > > While I don't (yet) want to completely > internationalize/localize the > > code, it is good to be aware of how Java approaches this and make a > > future move a bit less cumbersome. > > > > Also, regardless of the implementation, my bigger concern is that > > maintaining a help system that is intertwined with the code is > > excessively cumbersome and ought to be avoided by > everything but the > > earliest stages of development. > > Using a catalog-based internationalization system gets you > that for free. > As he mentioned, the tricky bit is handling cases where the order of > dynamically generated items or even their presentation can change. > > I have always found it easier to use the message catalogs from the > beginning rather than trying to retrofit them in after the project is > almost done. Once you get the base infrastructure setup, it > really isn't > much more work to use it than just putting strings straight > into the code. > > -- > John A. Tamplin ja...@ja... > 770/436-5387 HOME 4116 Manson Ave > Smyrna, GA 30082-3723 > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep > through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. > DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: John A. T. <ja...@ja...> - 2005-11-30 22:36:04
|
On Wed, 30 Nov 2005, Brett Lentz wrote: > While I don't (yet) want to completely internationalize/localize the > code, it is good to be aware of how Java approaches this and make a > future move a bit less cumbersome. > > Also, regardless of the implementation, my bigger concern is that > maintaining a help system that is intertwined with the code is > excessively cumbersome and ought to be avoided by everything but the > earliest stages of development. Using a catalog-based internationalization system gets you that for free. As he mentioned, the tricky bit is handling cases where the order of dynamically generated items or even their presentation can change. I have always found it easier to use the message catalogs from the beginning rather than trying to retrofit them in after the project is almost done. Once you get the base infrastructure setup, it really isn't much more work to use it than just putting strings straight into the code. -- John A. Tamplin ja...@ja... 770/436-5387 HOME 4116 Manson Ave Smyrna, GA 30082-3723 |
From: Erik V. <eri...@hc...> - 2005-11-30 23:30:57
|
At the moment, the game and game-state dependency of the help texts concerns me a lot more than internationalization. At one point I thought about creating a HTML file per game step, each one being a template to be run through a formatter to replace variables by real data (such as OR number, player/company turn etc.). This could (of course) be a file per language. But there seems to be too much variability between games to make this an easy approach. We would end up with a file per game, game step and language, and even then we would need some trickery to handle phase-dependent info (such as that mentioning the option to buy privates in 1830 should only show up in the green phase). Perhaps my original goal to exactly describe all currently available options at every point in time is too optimistic. Anyway, the only point I was trying to make so far is, that the help displayed by the UI must be provided somehow by the currently active Round subclass. That 'somehow' now consists of full HTML text, but it might well become some language-independent Help class, or just an array of resource bundle keys, that would be turned into language-dependent HTML by the GUI (possibly a different language per player). Just thinking aloud. Erik. > -----Original Message----- > From: rai...@li... > [mailto:rai...@li...] On Behalf Of > John A. Tamplin > Sent: 30 November 2005 23:36 > To: rai...@li... > Subject: Re: [Rails-devel] Re: HELP > > On Wed, 30 Nov 2005, Brett Lentz wrote: > > > While I don't (yet) want to completely > internationalize/localize the > > code, it is good to be aware of how Java approaches this and make a > > future move a bit less cumbersome. > > > > Also, regardless of the implementation, my bigger concern is that > > maintaining a help system that is intertwined with the code is > > excessively cumbersome and ought to be avoided by > everything but the > > earliest stages of development. > > Using a catalog-based internationalization system gets you > that for free. > As he mentioned, the tricky bit is handling cases where the order of > dynamically generated items or even their presentation can change. > > I have always found it easier to use the message catalogs from the > beginning rather than trying to retrofit them in after the project is > almost done. Once you get the base infrastructure setup, it > really isn't > much more work to use it than just putting strings straight > into the code. > > -- > John A. Tamplin ja...@ja... > 770/436-5387 HOME 4116 Manson Ave > Smyrna, GA 30082-3723 > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep > through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. > DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |