How to designate resources as do-not-translate?

Question

I work on the localization of Java software, and my projects have both .properties files and XML resources. We currently use comments to instruct translators to not translate certain strings, but the problem with comments is that they are not machine-readable.

The only solution I can think of is to prefix each do-not-translate key with something like _DNT_ and train our translation tools to ignore these entries. Does anyone out there have a better idea?

Answer 1

Could you break the files up into ones to be translated or ones to be not translated and then only send them the one that are to be translated? (Don't know the structure so har dto know when answering if that is practical...)

Answer 2

The Eclipse JDT also uses comments to prevent the translation of certain Strings:

How to write Eclipse plug-ins for the international market

I think your translation tool should work in a similar way?

Answer 3

Like axelclk posted in his link... eclipse provide a

//$NON-NLS-1$

Statement to notify the project that the first string in this line should not translated. All other string you can find by calling Source->Externalize Strings

External Strings include all languages you want to support.

File which include the translations looking like: PluginPage.Error1 = text1 PluginPage.Error2 = text2

Class which read the translation

private static final String BUNDLE_NAME = "com.plugin.name"; //$NON-NLS-1$

    private static final ResourceBundle RESOURCE_BUNDLE = ResourceBundle.getBundle(BUNDLE_NAME);

    private PluginMessages() {
    }

    public static String getString(String key) { 
        // TODO Auto-generated method stub
        try {
            return RESOURCE_BUNDLE.getString(key);
        } catch (MissingResourceException e) {
            return '!' + key + '!';
        }
    }

And you can call it like:

String msg = PluginMessages.getString("PluginPage.Error2"); //$NON-NLS-1$

EDIT:

When a string is externalized and you want to use the original string, you can delete the externalize string from all properties files, without the default one. When the Bundle can not find a message file which is matching to the local language, the default is used.

But this is not working at runtime.

Answer 4

The simplest solution is to not put do-not-translate strings (DNTs) in your resource files.

.properties files don't offer much in the way of metadata handling, and since you don't need the data at runtime, its presence in .properties files would be a side-effect rather than something that is desirable. Consider too, partial DNTs where you have something that cannot be translated contained in a translatable string (e.g. a brand name or URI).

"IDENTIFIER english en en en" -> "french fr IDENTIFIER fr fr"

As far as I am aware, even standards like XLIFF do not take DNTs into consideration and you'll have to manage them through custom metadata files, terminology files and/or comments (such as the note element in XLIFF).

Answer 5

If you do decide to use do-not-translate comments in your properties files, I would recommend you follow the Eclipse convention. It's nothing special, but life will be easier if we all use the same magic string!

(Eclipse doesn't actually support DO-NOT-TRANSLATE comments yet, as far as I know, but Tennera Ant-Gettext has an implementation of the above scheme which is used when converting from resource bundles to Gettext PO files.)