united-states canada discovery translation
Discovery process and evidence in a &quot;foreign&quot; language
<p>During the discovery procedure, the parties can obtain some evidence from the other party(ies) or non-parties. In the situation that interests me, one of the parties has evidence that is in a language that is not common to the other party or the court officials. How does the process work in this case?</p>
<p>Conditions:</p>
<ul>
<li><p>both parties are corporations within the court jurisdiction (say two US companies).</p>
</li>
<li><p>the requested evidence is internal communications (say e-mails) within one of the parties, which was performed in a foreign language (foreign in layman terms, say Swedish or Armenian when generally the company operates in English).</p>
</li>
<li><p>assume that the desired evidence would be possible to be obtained using a reasonably broad request if e-mails were written in English. For example:</p>
<blockquote>
<p>request any emails related to the patent infringement for &quot;abracadabra&quot; technology</p>
</blockquote>
<p>&quot;abracadabra&quot; is the English name of the technology, while it is &quot;hocus pocus&quot; in the language used within communications.</p>
</li>
</ul>
<p>What interests me, is if the company that will be fulfilling the &quot;abracadabra&quot; request is able <strong>to not provide &quot;hocus pocus&quot; emails</strong> (internally — or later in the litigation, if the truth is uncovered — justifying it that the team fulfilling the request does not speak the language and was unaware of the existence of these communications in a foreign language)? Are there legal mechanisms that prevent such defense using &quot;foreign language&quot;?</p>
<p>Tagged: US and Canada, as I would be interested to learn the practice in any of those two countries.</p>

<blockquote>
<p>What interests me, is if the company that will be fulfilling the
&quot;abracadabra&quot; request is able to not provide &quot;hocus pocus&quot; emails
(internally — or later in the litigation, if the truth is uncovered —
justifying it that the team fulfilling the request does not speak the
language and was unaware of the existence of these communications in a
foreign language)? Are there legal mechanisms that prevent such
defense using &quot;foreign language&quot;?</p>
</blockquote>
<p>The legal obligation in discovery is to produce compliant documents without regard to their language. Good faith efforts need to be used. Generally speaking, a mere single language boolean or key word search of a database is not a sufficient effort to meet that obligation.</p>
<p>Somebody was involved in writing the relevant emails and the lawyer and client representative needs to talk to the people who were involved, not just search a database, to make sure that all relevant materials are disclosed by whatever means are necessary to do so.</p>
<p>This is why discovery is often the most expensive part of litigation.</p>
<p>This doesn't mean that every good faith mistaken omission from discovery responses results in a court sanction if it is promptly remedied if later discovered. But, compliance requires engagement of the universe of possible documents with much more knowing and intelligent understanding that the question seems to assume.</p>
<p>For what it is worth, I have litigated a case in a U.S. court where none of the parties (nor the judge) was fluent in the relevant language (Italian) of most of the documents, but both parties understood and agreed on the meaning of the relevant Italian business documents (invoices and bank statements mostly running to hundreds of pages), and they testified to the judge regarding what those documents meant in English, without the relevant documents ever being actually translated in full by anyone. Language never became a meaningful issue, in part, because the more important issue was understanding the context of how the Italian banking system and commercial transactions were structured and once that was understood, the documents themselves were easily enough understood from context.</p>
