typical java i18n process - sending resource files to Translation companies to be translated

Question

There are loads of tutorials on using Java ResourceBundles to provide UI in multiple languages. However, there is a process question as regards typical interaction with translation companies that I can't seem to find an answer to.

Assuming for example that I don't know French, and need to employ a translation company to get translations for my app, would I send them

1. The default resource properties file "whatever_en_US.properties" including the key and English value, and get back "whatever_fr_FR.properties"?
2. "whatever_fr_FR.properties" with empty values and "whatever_en_US.properties" for reference?
3. some other combination?

Answer 1

To answer your question I would chose (2).

In practice I found that for me it is a lot easier to use something else rather than the Java resource bundles.

I personally use a different way of handling this. I use the gettext way (there is a file there called GetTextResource.java that you must use in your application to benefit from the gettext extensions - see here).

If you're familiar with gettext you will definitely find this approach a lot easier and practical. You simply give to your translators the po files (which can be edited with poedit). From the po files you create the java class you will use inside your application (this is done using msgfmt - specifying parameters for java compilation of the po files). Po files can be updated fairly easy using the xgettext command (from command line).

Of course everything is inside the gettext manual.

Advantages:

• gettext offers you a way to select the plural form [ No more messages like: "N file(s) deleted" (where N is a number) - see ngettext.

• a scriptable method for translating strings once your java files are updated with new tokens

• no need to access each string using some macros (like Translate(DELETE_BUTTON_MACRO) ). You just write your code like this:

  package translateutil;        
  import gnu.gettext.GettextResource;
  
  
  import java.util.ResourceBundle;
  
  
  import java.util.Locale;
  
  
  public class TranslateUtil
  {
  private static ResourceBundle myResources =null;
  
  
  public static boolean init(Locale loc, String resourceName)
  {
      boolean bRet = true;
      Locale.setDefault(loc);
  
  
  try
  {
      myResources = ResourceBundle.getBundle(resourceName);
  
  
      System.out.printf(  _("Current language: %s\n"),
                          Locale.getDefault().getDisplayName() );
  
  
      System.out.printf(  _("%s resource found\n"),
                          myResources.getClass().getName() );
  }
  catch(Exception e)
  {
      // let the application go on in English in case the ResourceBundle
      // was not found. Notify about the error
      bRet = false;
      System.out.println( e.toString() );
      myResources = null;
  }
  
  
  return bRet;
  
  
  }
  
  
  public static String _(String str)
  {
      if (myResources == null)
      {
          return str;
      }
      {
          return GettextResource.gettext(myResources, str);
      }
  }
  
  
  public static String _Plural(String singular, String plural, long param)
  {
      if (myResources == null)
      {
          if (param == 1)
          {
              return singular;
          }
          else
          {
              return plural;
          }
      }
      else
      {
          return GettextResource.ngettext(myResources, singular, plural, param);
      }
  }
  }
  

Here is a sample

    // example
    // similar for plural

    import static translateutil.TranslateUtil._;

    System.out.println(_("The english text"));

No matter what you choice is: Good luck!

Answer 2

Since your question is about a process and not about technology, I will try to give you thorough explanation. Assuming that you have application with no previous translation, the ideal process should look like:

1. Send English files for translation. Depending on your agreement with translation contractor you could use:

   • Your default properties files (you will be responsible for renaming them correctly)
   • Excell spreadsheet containing keys, English phrase and an empty column for translation
   • Gettext *.po file(s) if you are going to use gettext
   • Translation memory file(s) (i.e. Trados *.tmx files)

2. When you receive files back, you put these translations into product, create localized build and test it out. Surely, there will be some UI issues. Some of them you could fix on your own, some will require additional translation (like hardcoded strings), others will require shortening translation. Again, you will engage translation contractor and supply them with strings that need to be (re-)translated. You could use spreadsheet here (provided that there are not so many strings that need to be translated).

3. If you want to ship simultaneously (all languages at once), you need to engage translators early. Since UI strings will change (provided there is no hard-UI-freeze period or translation-freeze period), you will have to get your translations updated. In this case, you will need to supply already translated files with the strings that need to be translated (in English). If the changes are really small, you could send only the English strings and merge translations manually, otherwise it is best to use some kind of translation memory exchange format (gettext *.po's or trados *.tmx's are great here).

4. Translating files is usually not enough. Since usually there is no context given and different words may mean different things in a target language, translation errors occur. There is no way to know that they are in unless you know the language. That's why you need to take UI screenshots and send them out for review (it could be reviewed by your translation contractor, or somebody else depending on quality requirements).

5. Once reviewed, you will need to apply translation changes and test for UI issues...

That's about it, if we are talking about UI strings translation process. But please be advised that there is a lot of more to correctly localize an application (documentation, help files, icons, colors, sounds...).