Slashdot Mirror

Quote from their document:

UNL is designed with the following aims:
(1) UNL is to be capable of exactly representing all the information expressed in any language.
(2) UNL expression must be defined not only as rigorous but also as general as possible in order to be understood by any people who are engaged in the development of "enconverters" and "deconverters" in each language.

Not only is point one completely and utterly impossible for reasons well discussed here already (slang, local expressions, evolvement of languages etc.), point two actually contradicts point one! They want UNL to be an exact representation of the meaning expressed in the native language, while simultaneously having it to be generic enough so everybody (or at least all "enconverter" developers) can understand what is being said. Assuming the average "enconverter" developer will be as technically (il)literate as the authors of this document, there's no way they are going to understand what technical people are talking about even when using his native language. No way is UNL going to help with that. So how, then, is he going to understand that very same conversation translated from a language he doesn't understand in the first place? Forget it!

Nice idea. Store it in the bin with all the other equally nice ideas: "Health and food for all" and "Can't we all just get along?".

This is an excellent and very worthwhile project, but I have concerns about the approach. Here is the project schedule, which suggests that the order to do things is: first write UNL-to-native translators (1997), then write Native-to-UNL translators (1998), then test and deploy. The current UNL organization has three parts, one assigned to translator development, and two assigned to the design of UNL (semantics, linguistics, how it connects to HTML).

If the project organizers try to write good translators first, they will be putting the cart before the horse, and the project is likely to go badly. They should put their effort into the design of UNL, coming up with a good extensible machine-readable language that conveys human semantics, and write only prototype translators. UNL must be an open standard, like TCP/IP or HTML, and once publicly released, it should not drift too much. The writing of the real translators should be left to enthusiastic open-source developers, who will have the time and the motivation to do a much better job on translators.

Inevitably there will be trade-offs. In most languages, translations from other languages will seem like a pidgin. Fine linguistic nuances will not survive the translation process, and regular users will learn not to depend on them. If it's mostly comprehensible, it will still facilitate communication where none would have been possible previously.

The first design for UNL should probably be considered provisional, and ultimately a throw-away to be replaced in the future. But we can't replace it until we've learned its lessons. This still seems to me to be a very worthwhile thing to attempt.

This is an excellent and very worthwhile project, but I have concerns about the approach. Here is the project schedule, which suggests that the order to do things is: first write UNL-to-native translators (1997), then write Native-to-UNL translators (1998), then test and deploy. The current UNL organization has three parts, one assigned to translator development, and two assigned to the design of UNL (semantics, linguistics, how it connects to HTML).

If the project organizers try to write good translators first, they will be putting the cart before the horse, and the project is likely to go badly. They should put their effort into the design of UNL, coming up with a good extensible machine-readable language that conveys human semantics, and write only prototype translators. UNL must be an open standard, like TCP/IP or HTML, and once publicly released, it should not drift too much. The writing of the real translators should be left to enthusiastic open-source developers, who will have the time and the motivation to do a much better job on translators.

Inevitably there will be trade-offs. In most languages, translations from other languages will seem like a pidgin. Fine linguistic nuances will not survive the translation process, and regular users will learn not to depend on them. If it's mostly comprehensible, it will still facilitate communication where none would have been possible previously.

The first design for UNL should probably be considered provisional, and ultimately a throw-away to be replaced in the future. But we can't replace it until we've learned its lessons. This still seems to me to be a very worthwhile thing to attempt.