User information
 Loading ...
Show article in Knowledge Base

 Internationalization, terminology and language resource files.. Export knowledge base Export     SubscribeSubscribe      Show article info

How do I translate VisionProject grammatically correct with regard to the terminology options?

The new terminology options complicate translation/internationalization of VisionProject.

What is terminology in VisionProject? For some keywords (notably sprint, developer, issue), you can in Settings - Terminology choose which words should be used instead of the defaults. For example, you might choose Release, Assignee and Task instead of the above defaults (sprint, Developer and Issue), and these words will be used everywhere in VisionProject instead.


Translating VisionProject into a new language is a bit tricky, so this knowledge base article will try to explain how this works in the system with regard to the new terminology options (in the general/account settings). The biggest headache is that all the terminology predefined option words need to have several forms, with respect to grammatical case, gender and number.

In many languages, nouns (All of the terminology predefined option words are nouns) change form depending on its role in sentence - which is determined by its case, gender, number, definiteness, and other grammatical factors.

In many languages other words (articles, pronouns, adjectives, sometime prepositions, etc..) also change depending on the gender of the noun in the sentence (Different  predefined options may have different genders, thus affecting these other words as well).

This is why you usually cannot just have one key for 'sprint' and one option 'release' and 'do a search/replace', as is (almost) possible in english.

English as a language is a special case, as it does not have many of these features. Swedish (My own first language), is a little more complicated, but we still only have 2 cases, 2 genders, singular/plural, determined/indetermined. 8 possible forms for each word - but not all are actually used in the text. With other languages, there will probably be many more forms..



Note: Currently the terminology options are limited to sprints/developer. In the future, more options will be added. (Mainly 'issue', which occurs a great deal in VP, and will be added in the near future..)



The way to grammatical translation and terminology, is to use internal substitution in the property files.

(Take note that in the text below the term Version is used in the code,yet Sprint is the term used in the user interface)


What is this internal substitution? If you look in the ApplicationResources property file, you'll notice that for each type of predefined option term, there is a 'nomen' section of key/values. These are the original substitution keys.. In the main body of the application resource you can substitute say, @{nomen.version}@ for 'version' in the value text.

What do we gain from this? Well, take a look at the nomen.predefinedOptions sections, which have lines like this:
(This is a predefined option for 'sprint' -> 'milestone' (version.milestone), and this particular row substitute 'Milestones' for the substitution key '') By changing predefined option, you will update the substitution key value, affecting all the relevant substitution in the body of the application resource file.



Here are some sample 'nomen' lines for 'sprint' in swedish. (And, yes the terminology is a bit ungrammatical/bastardized, '..theversions..' :) Will possibly be changed in future. 'theversions' etc.. are used as swedish have its articles as suffixes))


One word, many inflections, results in many rows

You will probably have to add quite a few new rows of internal keys with grammatical inflections of words in your application resource file (Example ApplicationResources_cs_CZ for czech language).

You might have to add lines like this (assuming that nominative is default and not noted, like in nomen.version):

nomen.gen.version=(genitive form of version)
nomen.ack.version=(accusative form of 'version')
nomen.ack.versions=(accusative plural form of 'version')
nomen.ack.theversion=(accusative determined form of 'version')
nomen.dativ.version=(dative form of 'version')
nomen.loc.version=(locative form of 'version')
nomen.instr.version=(instrumental form of 'version')

Note: Do not forget to add these new rows to the correct section of ApplicationResourceCategory! (with key value 'Special category|n', where n is a number)


(The actual types of key/values added depends on the grammar of the language - not all languages have all cases in the example above)

This is many possible forms for each word.. for simplicity, you should only add the combinations actually used in actual text, like this sample key:
aaa.bbb.ccc.ddd=Bla bla bla @{nomen.ack.version}@ bla bla @{nomen.dativ.developer}@ bla..
Unused rows might be present for future use, but commented out, like this:


One set of keys for each predefined nomenclature option

You have to add the same set of rows for each terminology predefined option.. and possibly other words that are affected by the gender of the terminology word - I had to add some small words and adjectives as well, for the swedish version, as they varied with the terminology option.  (a new issue/task - ett nytt ärende/en ny uppgift)


Remember that the nomen.predefinedOptions must mirror the associated nomen. section - have the same number of rows, and that all the keys must be added to the ApplicationResourceCategories file!


(Another note: The number of predetermined options need not be the same across languages. For example if English have 5 options for 'issue', and your language only have 4 good words for the concept, it is perfectly fine to have 1, 3, 4 options, or even 6 or 10..  But all terms in the option sections must mirror the base nomen section for 'issue', in that example.)


Swedish sample predefined option section:

(As you see, it is two sections - one for the capitalized words, one for those without capitals. Some words only show in one list, though.  This option would replace the swedish default 'Ärende' (Issue) with this option -'Uppgift')


#Predefined option term list - Task - Matches for ex: key aboveÄndrad



The anatomy of a predefined option key:

Let us take a look at one of the keys in the example above: nomen.predefinedOptions.issue.task.nomen.theissues=uppgifterna

The long key is a concatenation of three flags, joined using punctuation:

  • nomen.predefinedOptions - The first section tells us this is a predefined option key, whose value can replace the default if the option is chosen.
  • issue.task - This part tells us which substitution is taking place: issue -> task, or in this case, the swedish equivalents. In a predefined option that substitutes say, release for sprint, this section would be named version.release, for example.
  • nomen.theissues  - The last section refers to the actual key that will be replaced if this option is chosen. In this case, the key nomen.theissues (with the value 'ärendena' in swedish - determined plural of the default 'ärende') would be replaced with the value of the sample key ('uppgifterna', as shown above)


Whenever you choose the terminology option 'Uppgift' (task) instead of the default 'Ärende' (issue) in the swedish terminology page, the sample row would make sure that everywhere in VisionProject says 'ärendena' (the issues) would instead read 'uppgifterna' (the tasks).


An international example

Thus, when I want to have a key that says for example: 'A new issue must be created!', then I write it like this:{}@ @{}@ @{nomen.issue}@ must be created!
or in swedish:{}@ @{}@ @{nomen.issue}@ måste skapas!

Hard to read, yes.. but here's how the sample text finally turns out for two swedish predefined options for 'issue': ärende/uppgift - these words have different gender and will affect the inflections of the words 'a/an' and 'new' in this sentence:

  • Ett nytt ärende måste skapas!
  • En ny uppgift måste skapas!


And finally, when the application resource file is done, substitutions and all, there are still some things that may need to be done through code and database changes (example: developer is also a name for a user group - needs to be changed in db for a chosen option..)

Yes, implementing terminology options with grammatically correct internationalization, is a headache.. :)

User comments
 Loading ...