CIT 591 Language Translation Additions
Fall 2005, David Matuszek

Purposes of these additions:

Added functionality:

Yoda is a little green alien. He speaks English, but his grammar is a little funny. Extend your language translator to handle "Yoda-speak" ("Yoda" for short).

Translation details:


Translate the words to English.

Verb rule: Apply the English verb rule, then move the verb, along with any preceding noun (NOUN), determiners (DET), and adjectives (ADJ), to the end of the sentence. So, for example, "the man sleeps on the table" becomes "on the table the man sleeps".

Adjective rule: Same as English.

Since Yoda uses the same words as English, when translating Yoda → English or English → Yoda, the easy thing to do is to use the English word list as both the "from" word list and the "to" word list. You could save a few nanoseconds by omitting the word-by-word translations. This is a good example of the kind of optimization you should not make.

Notice that our verb and adjective rules depend only on the "to" language, not on the "from" language. This makes certain translations more of a problem. In particular, while you should be able to translate English to Yoda reasonably well, going from Yoda to English may not do anything, or it may mangle the sentence. Don't try to fix this. Your job, in this case, is to try to get the translation project funded for another year.

Javadoc details:

Document everything that has public, protected, or "package" access. You are welcome to document things that have private access, but this is not required. Do not put Javadoc comments where they do not belong, such as in front of local (method) variables.

For each class or interface, provide:

For each constructor, provide:

For each method, provide:

For each constructor, provide the same kind of information as for a method, except that you should not have a @return tag for a constructor.

For each instance variable or static variable, provide:


Often you will find yourself explaining the parameters to a method (or a constructor) twice, once in the description of what a method does, and again in the @param tags. This is somewhat unavoidable, but if you have a good general description, you can be very brief in the @param tags.

Avoid describing methods in terms of other methods. Insofar as possible, each description should make sense all by itself.

You should not use static or instance variables for temporary values, such as the index of for loops. Every such variable should say something about the object in which it occurs; if it doesn't, it's in the wrong place.

Revised classes and methods:

I have added some buttons to the class, which you should download and use in place of the previous version. If you compare these two versions, you will see that I did not need to add anything to the code except the buttons themselves.

I did not change the dictionary classes and Remember, you are welcome to add words of your own to the dictionary (Hint:, but please don't remove any.

You will need a new class, YodaRules, which implements RuleSet.

In the constructor for your LanguageTranslator, you will need to add some code to deal with the "Yoda" language. This added language should only affect the constructor. Other methods, and in particular the translate method, should not need to be changed. If you do need to change them, you aren't making good use of interfaces.

I said that your RuleSet interface should declare the following methods:

void applyVerbRule(String[] words);
void applyAdjectiveRule(String[] words);

This can be made to work, but it's a lot more awkward than I intended, because the methods aren't getting part of speech (NOUN, VERB, etc.) information. If you wish, you can declare the methods this way instead:

void applyVerbRule(String[] words, String[] types);
void applyAdjectiveRule(String[] words, String[] types);

where the second array tells you the part of speech of each word in the first array. For example, if the first array contains {"The", "table", "is", "red"}, then the second array would contain {"DET", "NOUN", "VERB", "ADJ"}. I think this will make your code a lot simpler, so the best reason for not doing it this way is if you already have the program working with the old method declarations.


We will pay careful attention to formatting and style.

Due date:

October 27, before midnight, via Blackboard only.