| [babel-dev] Simpler pseudo-locale (and Unicode) testing (finding non-externalised strings in the UI) |
I would like to make it easier to test issues like string externalisation. I have been submitting a number of "unexternalised string" bugs against various Eclipse components: http://dev.eclipse.org/mhonarc/lists/babel-dev/msg00598.html My bug reports include the customary Steps To Reproduce: 1. Install the Babel Pseudo English langpacks from http://www.eclipse.org/babel/downloads.php (update site: http://download.eclipse.org/technology/babel/update-site/ganymede ) 2. Run eclipse with the option "-nl en_AA" to activate the langpack 3. [blah blah blah] I wouldn't expect most programmers to be very keen on following those steps. Step 1 is a real hand-wave. Frequently installing langpacks (eg nightly ones, to test nightly code changes) can be very painful, especially if you run self-hosted Eclipse, as most Eclipse devs probably do, since P2 goes on strike in self-host mode. Besides, if I just externalised a string in my source code, I'd rather not wait until the next nightly build of Babel before testing my work! For those components which use the Eclipse externalisation mechanism, a small enhancement to the class org.eclipse.osgi.util.NLS [or a fragment plugin] could enable on-the-fly pseudo-localisation. If NLS.initializeMessages saw that the current locale is say "qps" it could dynamically produce pseudo-localised strings based on the original English. For instance, this is the pseudo-localiser I'm using in JBoss Tools testing (statically at present, not dynamically): https://fedorahosted.org/tennera/browser/trunk/ant-gettext/src/main/java/org/fedorahosted/tennera/antgettext/StringUtil.java It can convert from (a) "No enclosing instance of type {0} is accessible to invoke the super constructor. " into (b) "[--- Nø éňçŀøšîňց îňšŧåňçé øϝ ŧŷｐé {0} îš åççéššîЬŀé ŧø îňⱱøⱪé ŧⱨé šմｐéя çøňšŧяմçŧøя. ---]". If your email client (and everything in between) handles Unicode properly, and you have the right Unicode fonts, the string (b) is just about readable. You get used to it, trust me!. Obviously, you wouldn't want to do your day-to-day development in that locale, but that's not the idea. Note: this is just an example of Unicode pseudo-localisation. You might want to make the strings longer/shorter, use more common or more readable Unicode fonts, maybe even include ResourceBundle property keys [or a hash thereof]. I think dynamic Unicode pseudo-localisation has most of the benefits of the "eclipseNNNN:original English text" method: 1. Shows whether each string was externalised 2. Shows if externalised text has been concatenated 3. Shows how the GUI handles extra-long translations 4. Leaves the GUI almost as well as usable as the original English locale, unlike a foreign language Plus some extras: 5. Shows you whether the application handles Unicode 4.0 (supplementary chars) and has at least some Unicode fonts. 6. Just as up to date as your code is 7. Never needs to be installed In the version I've described above, it doesn't tell you the property key for the resource bundle (which you can get from en_AA by looking up eclipseNNNN in BabelPseudoTranslationsIndex-eclipse.html) but if that's a problem, a hashcode of the key could be added. In any case, I wouldn't want to replace en_AA. Knowing that a string has actually been processed by Babel is valuable information too. I think both types of pseudo-localisation are useful. A couple of links on pseudolocales and choosing their IDs (interoperability is good!): http://msdn.microsoft.com/en-us/library/ms776399(VS.85).aspx http://blogs.msdn.com/michkap/archive/2007/02/04/1596987.aspx Regards Sean. -- Sean Flanigan Senior Software Engineer Engineering - Internationalisation Red Hat
Attachment:
signature.asc
Description: OpenPGP digital signature