This seems like a solved problem: agree at the time which translation takes precedence in the event of a dispute. Use a third language (historically French was the language of diplomacy, now English, but for modern treaties you could pick any major world language) if, as is likely, neither side likes the idea of the binding version being in the other side's language. The same problem has to be solved in countries wit…
Lost in Translation: Writing treaties in two languages can lead to problems
31–40 of 46 posts
Re: Lost in Translation: Writing treaties in two languages can lead to problems
#32As a software engineer who cares deeply about testing, I sometimes find myself wishing that there was a way to run a binding moot court on a law before it got ratified.
Re: Lost in Translation: Writing treaties in two languages can lead to problems
#33Earlier quoted context omitted.
Third party language implies that either citizens of country 1 must learn this third party language to the proficiency needed to understand legalese; or to both be expected to know, understand and apply the law but not be able to read it.
Could Latin perhaps fit the bill? It's already popular with lawyers
Lawyer here — very few of us know more Latin than the odd artifact such as ejusdem generis or contra proferentem, which occasionally are relevant to contract interpretation. And those of us of a certain age who grew up Catholic will remember bits and pieces of the old Latin Mass. Otherwise, Latin is probably as dead to lawyers as to anyone else.
English is now the global lingua franca; while I used to be a grammar vigilante, not long ago it occurred to me that in the linguistic "marketplace," if we native speakers want English to outcompete, e.g., Mandarin or Spanish, we need to be willing to let the language evolve so that it's easier for non-native speakers to learn and use confidently.
Re: Lost in Translation: Writing treaties in two languages can lead to problems
#34https://en.wikipedia.org/wiki/Lojban
I wonder if the cost of having people learn to use a logical engineered language is greater or less than than the cost of hashing out ambiguities in other languages later.
Re: Lost in Translation: Writing treaties in two languages can lead to problems
#35Earlier quoted context omitted.
Which is my second point: citizens will have to follow and vote on the law of their country, including international treaties, without understanding them since they are not written in their language.
AIUI, a treaty is not law unto itself. Rather, the parties to a treaty will pass laws that implement said treaty.
Once a treaty enters into effect, a nation is bound by the terms of the treaty even if they do not have implementing laws. However, in many cases treaties don't have any consequences if signatories don't pass implementing laws (see, e.g, the Kyoto Protocol).
Re: Lost in Translation: Writing treaties in two languages can lead to problems
#36As a software engineer who cares deeply about testing, I sometimes find myself wishing that there was a way to run a binding moot court on a law before it got ratified.
As a software engineer, I laugh bitterly every time a lawyer tells me that they are being rigorous in their interpretation of a law. Even when all the lawyers agree on interpretation, their notion of "rigor" bears no resemblance to the way a computer applies the term. A test engineer would have zero problem fuzz-testing a law into nonexistence.
What programmers consider rigorous testing is literally just automated, predetermined situations that often have little resemblance to the ways end users actually use (and break) the software.
Re: Lost in Translation: Writing treaties in two languages can lead to problems
#37I'd be interested to see if anyone has attempted to write legal documents using a logical engineered language like Lojban. https://en.wikipedia.org/wiki/Lojban I wonder if the cost of having people learn to use a logical engineered language is greater or less than than the cost of hashing out ambiguities in other languages later.
Re: Lost in Translation: Writing treaties in two languages can lead to problems
#38> In the United Nations Security Council (UNSC) Resolution 242, the French text instructed Israel to withdraw from ‘des territoires’ (the territories) it occupied during the 1967 Six-Day War. The English text, however, merely read ‘territories’, removing the definite article and thus leaving ambiguous how much territory Israel should cede. This is inaccurate. « Des territoires » would be more accurately translated as…
This is obvious weasel wording. during the writing of the resolution it was made clear that it meant all the territories. This is how it was phrased: >(i) Withdrawal of Israeli armed forces from territories occupied in the recent conflict; any native enlgish speaker can read the declaration and see from the contest that it clear that all territories taken during the war are meant. The Israelis came up with this facet…
Re: Lost in Translation: Writing treaties in two languages can lead to problems
#39As a software engineer who cares deeply about testing, I sometimes find myself wishing that there was a way to run a binding moot court on a law before it got ratified.
As a software engineer, I laugh bitterly every time a lawyer tells me that they are being rigorous in their interpretation of a law. Even when all the lawyers agree on interpretation, their notion of "rigor" bears no resemblance to the way a computer applies the term. A test engineer would have zero problem fuzz-testing a law into nonexistence.
Re: Lost in Translation: Writing treaties in two languages can lead to problems
#40Earlier quoted context omitted.
As a software engineer, I laugh bitterly every time a lawyer tells me that they are being rigorous in their interpretation of a law. Even when all the lawyers agree on interpretation, their notion of "rigor" bears no resemblance to the way a computer applies the term. A test engineer would have zero problem fuzz-testing a law into nonexistence.
You should have seen developers rigorously implement requirements. Just saying.
Programmers want rigid requirements, because that makes their job easier. Indeed, it does their real job for them. If we had a really rigid way of writing specs, you'd just write a compiler for it. The real job of a programmer is precisely about playing intermediary between the true rigor of the computer and the pseudo-rigor of requirements.