views:

93

answers:

6

I have a phrase in English that looks like this: "I have {0} dogs and {1} cats". In code, I provide the data with a String.Format:

String.Format("I have {0} dogs and {1} cats", 1, 2)

So the output is this: "I have 1 dogs and 2 cats".

The problem that I'm trying to solve is the phrase "I have {0} dogs and {1} cats" needs to be translated in other languages.

In this Spanish translation example, the English phrase "I have {0} dogs and {1} cats" and the translated phrase "Tengo {0} perros y gatos {1}" are stored in a database.

If the user were to change "Tengo {0} perros y gatos {1}" to "Tengo {0} perros y gatos {3}", a System.FormatException will be thrown when I call String.Format("Tengo {0} perros y gatos {3}", 1, 2).

For now I'm trapping the format exception and it feels wrong. I'm looking for ideas on a better solution.

A: 

Nightly unit tests can catch this problem.

Another idea:

Give this user a checker tool which the user can run after making changes.

Hamish Grubijan
+1  A: 

Well, I think your users shouldn't be able to change your translation string unless they know what they're doing. Usually, translators should be told that the {0}, {1} represents replacable parameters and should not be altered. All other people besides translators should have no access to these strings, IMHO.

Webleeuw
I still need to account for mistakes that the "translators" will make...
Coov
+1  A: 

There are two things you could do :

  1. Check that this does not happen when the translator saves the new translation, ie you could search for {XX} and see if the maximum number is different from the original translation. If so, don't save the new one.
  2. When displaying it, if there is an error like that, catch the exception and fall back to the default language that you know is correct.
Wookai
+4  A: 

Before saving to the database, why not see if you String.Format throws? If so -- do not let the user save.

Just a simple idea that may solve the problem...

Ian P
I do have a "Translation Manager" interface that the users type their translation into. Adding a check there is a good idea. +1
Coov
Trying a function just to see if it throws an exception really isn't an acceptable form of validation.
Joshua
@Joshua How would you maintain the integrity of the placeholders in the string?
Coov
Yeah, just make sure the curly brace values match in the validation. Not a big deal
Mike Sickler
+1  A: 

I would compare the translated phrase with the stored original phrase, to check if the number and types of placeholders are equal.

Parse the original English phrase, and check for placeholders, e.g. using a regex: /\{\d+\}/ (if you only use placeholders and no formatting). Check the matches, and compare them at edit-time to the translated string. This makes sure the application fails at a time the user can still correct it.

Kamiel Wanrooij
+1  A: 

You definitely need a validation function that can check the edited string in some way. Even in a different scheme that didn't use number position indicators there would still be opportunity for typos.

In terms of UI, after they finish their edit, you could show them a sample translation that actually fills in the parameterized values. This would serve the double purpose of validating their formatting string and giving them a visual double-check of how it will look in context.

Jeff Kotula
Jeff, Good idea here. +1
Coov