Community
Participate
Working Groups
Following the advice in "How to Test Your Internationalized Eclipse Plug-In" (http://www.eclipse.org/articles/Article-TVT/how2TestI18n.html) section "Testing for hard-coded strings", I suggest that Babel automatically provide a graybox language pack for projects to use to search for hard-coded strings.
Created attachment 89045 [details] pseudo translations The design suggested by the article serves only one purpose: identify hard-coded strings. I'm proposing another design by inserting a special prefix to each string in each properties file. The prefix is comprised with 2 parts. The first part is a component name, like Eclipse, WTP, etc. The second part is a unique number. See screen capture for an example. This approach serves multiple purposes: - identify hard-coded strings; a string is hard-coded if it does not have the special prefix - the added length to the strings can help identify layout problems; for example, after adding "Eclipse123456" to "OK", a button label is truncated. - identify the component the string is coming from; is the string from Eclipse Platform or from my component? - locate the file containing the string; there are probably a dozen copies of the strings "File" or "OK". If you want to locate a particular one to fix the translation, you just have to look up the prefix number from an index file. Another detail about the implementation. We should use a special locale like en_ZZ this NL packs. You will see all these special tags when running Eclipse with -nl en_ZZ. When Eclipse (actually, Java ResourceBundle) cannot find a string in the NL pack (because a string is hard-code), it will default to load the English string.
So all that needs to happen here is hack into the build process to create a language pack for en_ZZ which generates translations for English strings in the format of projectname (concatenated with) somenumber (concatenated with) the actual English string? Increasing priority -- many people are asking for this.
Yes, that will serve as one simple form of pseudo translations. Please use "en_AA" as the locale for this language pack. There is another favor of pseudo translations which is more fancy and could be used to test other globalization enablement problems. (I will use "en_ZZ" for that.) I will open a separate bug to explain the implementation details for that.
There are strings in some properties files that should not be translated, or else Eclipse may not come up or may not work properly. For example, if the key "hook.configurators" in "eclipse\plugins\org.eclipse.osgi\hookconfigurators.properties" is translated (or modified by the pseudo translation language pack script by adding a prefix), Eclipse will not start. Therefore, this bug depends on bug 226378. We need a bit for each string in the database to indicate if the string is translatable or not. If a string is not translatable, we should skip adding a prefix for the string in the pseudo translation language pack.
Created attachment 113121 [details] patch I've implemented the generation of Babel Pseudo Translations Language Packs. Follow the instructions at http://www.eclipse.org/babel/downloads.php to add the Babel Language Pack Update Site, select and install the "Pseudo Translations Language Pack", and start Eclipse with -nl en_AA. I will post a link to a doc on how to use the Babel Pseudo Translations Language Packs at the Babel Wiki soon.
Created attachment 113122 [details] screen capture Just a quick summary again, the Babel Pseudo Translations Language Packs can help: - identify hard-coded strings; a string is hard-coded if it does not have the special prefix - the added length to the strings can help identify layout problems; for example, after adding "Eclipse123456" to "OK", a button label is truncated. - identify the component the string is coming from; is the string from Eclipse Platform or from my component? - locate the file containing the string; there are probably a dozen copies of the strings "File" or "OK". If you want to locate a particular one to fix the translation, you just have to look up the prefix number from an index file. Notes: - The Babe Pseudo Translations Index file can be found at eclipse\features\org.eclipse.babel.nls.en_AA_<feature-version>\BabelPseudoTranslationsIndex.html . Clicking on the link in the index file will bring you to the string at the Babel Translation Server. - I do not have the latest release train projects defined in my development evnironment. Therefore, some strings do not have the prefix in the screen capture.
(In reply to comment #5) > Follow the instructions at http://www.eclipse.org/babel/downloads.php to add > the Babel Language Pack Update Site, select and install the "Pseudo > Translations Language Pack", and start Eclipse with -nl en_AA. I propose to make this language pack available only from the nightlies server, since ‘ordinary users’ need not be bothered with it. I.e. provide it on http://build.eclipse.org/technology/babel/test-updates/ganymede/, but not on http://download.eclipse.org/technology/babel/update-site/ganymede. I don’t really know whether it would make a point to provide it for Europa as well. When is it going to be there?
Hendrik, The goal of the Babel project is to globalize all the Eclipse projects with the help of the Eclipse community. The pseudo translations language packs are not just a tool for developers to identify unexternalized strings and layout or label truncation problems. It's also a tool to make it easier for end users to locate strings with incorrect translations and contribute translations back to the community. Therefore, I think it's appropiate to make the pseudo translations language packs available at the live update site. Although developers may not have any more code changes for Europa, the translation effort of projects in Europa is still underway in many languages. The pseudo translations language packs for Europa can help translators to locate where strings come from. It's still a needed tool in Europa. As soon as the patch is reviewed and applied on the staging server, and after the language packs are reviewed, we will make it available at the live update site. Thanks! Kit
(In reply to comment #8) > Hendrik, > > The goal of the Babel project is to globalize all the Eclipse projects with the > help of the Eclipse community. The pseudo translations language packs are not > just a tool for developers to identify unexternalized strings and layout or > label truncation problems. It's also a tool to make it easier for end users to > locate strings with incorrect translations and contribute translations back to > the community. Therefore, I think it's appropiate to make the pseudo > translations language packs available at the live update site. ACK, but those people that really want to bother to install a very peculiar language package, figure out how to enable it and look for that particular string, don’t you think we can think of them as ‘developers’ in the sense of active translators. I do not think that the occasional user that notes a malformed string or whatever will bother. If we’re lucky, he’ll report it on Bugzilla and it is then the task of the language team (or however that is supposed to work, is it already possible to choose particular localizations as bug targets?) to find out which string it is. For the purpose of quickly fixing something, I think it is much more appropriate to offer a search functionality à la lxr for Eclipse, as I asked for in another bug. I think the official update site should be reserved for ‘released’ language packs (although this is also still a problem, see the multitude of problems with installing them), and this kind of thing deserves its place at the test server.
Denis and Gabe, please review and apply to staging server for testing.
Kit, you've hacked generate1.php quite heavily, but it looks alright. Go ahead and commit this to CVS and I'll run a build from the staging code to see how it fares. Do we need to add a language to the languages table?
Patch released to CVS repository. We do not need a new language in the languages table for 2 reasons: 1) even if we added a new pseudo language (en_AA), the SQL query to list all plugins with translations has to be hacked anyway because there will be no real translations in the translations table (pseduo translations are generated on the fly) 2) we should not have an English (en) language pack anyway. (en_CA and en_GB language packs is a different story, see bug 217339 .) Therefore, I "borrowed" the "en" language to generate the pseudo translations. However, in the release_train_projects table, we do need to map a release to a version number (e.g. Europa to 3.3, and Ganaymede to 3.4) because we need a version number in the feature. I will open a separate bug for that.
Kit, I opened 248835 today to version release trains.
(In reply to comment #13) > Kit, I opened 248835 today to version release trains. That's great! Once that's done, I will touch up the code to remove the hard-coded release train version number.
I ran my publish script for a language pack based on the Staging code and data. The script essentially does this: cd /home/data/httpd/babel.eclipse.org/staging/classes/export/ php5 generate1.php cd /home/babel-working/staging/output This is what I got back. Essentially, the build failed. genie@babel:~> ./publishPackFromStaging.sh PHP Warning: session_start(): open(/var/lib/php5/sess_0pe6vu643bp5qvdcqdao9ndha1, O_RDWR) failed: Permission denied (13) in /home/data/httpd/babel.eclipse.org/staging/html/global.php on line 65 PHP Notice: Undefined index: REQUEST_URI in /home/data/httpd/babel.eclipse.org/staging/html/global.php on line 77 PHP Notice: Undefined index: REQUEST_URI in /home/data/httpd/babel.eclipse.org/staging/html/global.php on line 78 PHP Notice: Undefined index: REQUEST_URI in /home/data/httpd/babel.eclipse.org/staging/html/global.php on line 79 PHP Notice: Undefined index: HTTP_HOST in /home/data/httpd/babel.eclipse.org/staging/html/global.php on line 110 Generating update site Completed generating update site PHP Warning: Unknown: open(/var/lib/php5/sess_0pe6vu643bp5qvdcqdao9ndha1, O_RDWR) failed: Permission denied (13) in Unknown on line 0 PHP Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php5) in Unknown on line 0
I ran into similar messages before in my development environment. What I noticed was the InitPage() function in global.php was checking for the User object. I only have my own userid in my SQL DB in my development environment, but not the "babel" userid. Therefore, as a hack for my development environment, I commented out the InitPage(""); call in generate1.php and hard-coded the following calls: mysql_connect("localhost", "babel", "babelpassword"); mysql_select_db("babel"); Is it possible that the "babel" userid is not in the SQL DB in the staging server?
Created attachment 113884 [details] patch to call dbconnection.class.php instead We don't really need all the functions in global.php, except toescapedunicode(). The code in InitPage() to find the User object and fetch username from session may have problems in command line. I refactored toescapedunicode() into common_functions.php and simplified generate1.php in include common_functions.php and dbconnection.class.php instead. Denis, please try the generation again. Thanks!
I ran generate1.php in the staging context, and it was successful. I had to put a conditional around the rm -rf $work_dir statement, as it would fail on the server. You can use this update site to test: http://build.eclipse.org/technology/babel/staging-updates/ This update site contains relatively old translation data from the live server.
Thanks Denis! I tested the staging update site. Everything is working as I expected! We don't have many language packs generated only because the staging server contains relatively old translation data. Once we deploy the code to the live server, we will generate all the correct language packs!
Released > R_0_200810171322
