XML attribute value indirection
|
View:
New views
3 Messages
—
Rating Filter:
Alert me
|
 |
XML attribute value indirection
by Carlsbad Cubes mailing list
::
Rate this Message:
I would like to weigh in on the side of indirection.
My experience was as part of a very small company (I was the software guy), where I created our application initially in English. When we ready to translate, all the translator would have to do is edit ".ini" files, which only consisted of key=value. I was even nice enough to have separate files, e.g., ids.ini for dialog/menu fields, and help.ini for setToolTipText. For a decent sized application, i.e., one with 30 or so dialogs, there were about 1000 ids.ini and 500 help.ini lines to translate. But there's more - we had about 6 separate applications. Well, for each application, there was a global ini file that could be shared (how many times do you have to translate: "File not found: "). Bottom line - over 3000 lines to translate. But as painful as this sounds, it was a no-brainer to determine with a few short ksh scripts if the translator accidentally deleted/mangled a line. This was only possible because the translator was 100% isolated from the dialog/menu files, because I made it a policy to never have a single line of "English" in the dialog/menu files. Finally, I bundled all the translations in a a single res.jar. Now it's 2005. I've tossed all my home grown code from reading ".ini" files and now use ini4j from SourceForge (it uses Properties rather than BundledResources). I am *not* an authority on SwixML, having only used it for less than one week, however, I would find it nearly impossible to guarantee the integrity of a translation if the xml files are edited directly. *Every* field in the xml file should be exposed to indirection. Further, to have the xml files directly exposed directly, rather than bundled in a jar file is not acceptable (do you honestly want to let uses to fool around with the xml files?) . I was successful passing to swix.render a URL for the .xml from a jar file, but gave up trying to pass a translation file via URL. Now if you ever change you mind, I would suggest button text="${ok} /> rather than button text="@ok" /> because it would allow for a more sophistacted buttontext="${how}${now}${brown}${cow}". This is not my idea, ini4j also allows "{@prop/key}" if coming from the properties file and {@env/key} if coming from the environment. Very cool. Steve _______________________________________________ Forum mailing list Forum@... http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com |
|
|
Re: XML attribute value indirection
by Carlsbad Cubes mailing list
::
Rate this Message:
List for Users of Carlsbad Cubes' Technologies and Products <Forum@...> schrieb am 20.10.05 17:21:11: > ... Further, to have the xml files directly exposed directly, > rather than bundled in a jar file is not acceptable (do you honestly > want to let uses to fool around with the xml files?) . I was successful > passing to swix.render a URL for the .xml from a jar file, but gave up > trying to pass a translation file via URL. Steve, I do not understand: You could not put your translation files into a jar? If this is your only problem and reason for indirection, there is a cure for that. Of course neither the xml files nor the .properties files are'nt exposed to "fool around with". Here are snippets from (one of) my build.xml: <property name="build.dir" location="build"/> ... <target name="dist" depends="..." description="..."> <jar jarfile="${build.dir}/ipd-${version}.jar"> <manifest> <attribute name="main-class" value="..."/> <attribute name="class-path" value="..."/> </manifest> <fileset dir="${build.dir}"> <include name="**/*.class"/> ... </fileset> <fileset dir="${resource.dir}"> <include name="**/*.properties"/> <include name="**/*.gif"/> <include name="**/*.png"/> <include name="**/*.xml"/> <include name="**/*.xsl"/> <include name="**/*.txt"/> <include name="**/*.dtd"/> <exclude name="**/*.bak"/> <exclude name="**/*~"/> </fileset> </jar> </target> <path id="classpath"> <pathelement path="${build.dir}" /> <pathelement path="${resource.dir}" /> <fileset dir="${lib.dir}" includes="**/*.jar" /> </path> <target name="run" depends="compile" description="runs"> <java fork="true" classname="..." classpathref="classpath"/> </target> The bundle attributes in my swixml files are in no way special like: <frame size="990,700" title="..." bundle="i18n.messages" id="mainframe" defaultCloseOperation="WindowConstants.DO_NOTHING_ON_CLOSE"> My resource files are located (as you may have guessed) in ${resource.dir}/i18n/messages*.properties To summarize, I do not have any other files than jar files to distribute my app with (ok, one: a dtd file I cannot get rid of, but this matter is not swixml's). The jar/distribution subject can be resolved entirely without indirection... > > Now if you ever change you mind, I would suggest button text="${ok} /> > rather than button text="@ok" /> because it would allow for a more > sophistacted buttontext="${how}${now}${brown}${cow}". This is not my > idea, ini4j also allows "{@prop/key}" if coming from the properties file > and {@env/key} if coming from the environment. Very cool. Hm, IMHO this can be done through a change to StringConverter, just split the text and call the localizer for each part... Yours, Frank > > Steve > > > _______________________________________________ > Forum mailing list > Forum@... > http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com _______________________________________________ Forum mailing list Forum@... http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com |
|
|
Re: XML attribute value indirection
by Carlsbad Cubes mailing list
::
Rate this Message:
Frank,
My apologies. After ranting (just a little) earlier, I took a different tack - I wrote a tiny ResourceBundle, where handleGetObject distinguishes between text="${foo}" and text=foo, as Babak needed. It was then easy enough to do a swix.setResourceBundle(Bundle.Name). Your approach is much more sophisticated, but I couldn't figure out to overload ResoureBundle.getString any other way. Do you have a (simple) workaround for Babak's Font=xxx problem? Again, I'm a newbie, but I just don't understand why all fields can't be exposed to indirection. By exposing "all", SwixML is giving the developer a choice, but he/she doesn't have to take advantage of it, nor is SwixML necessarily increasing complexity. Steve List for Users of Carlsbad Cubes' Technologies and Products wrote: List for Users of Carlsbad Cubes' Technologies and Products Forum@... schrieb am 20.10.05 17:21:11: _______________________________________________ Forum mailing list Forum@... http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com |
| Free embeddable forum powered by Nabble | Forum Help |
