How to START Localize End-User Docs

Many web-services and cloud-based platforms want to scale their business and quantity of active users. Such wishes push them to enter foreign markets and, in respect to streaming platforms, produce content in different languages. START, the video streaming service, increases its presence in new regions and has developed an international version of its own platform to achieve this purpose. To do so, we faced with a new task: we need to localize the interface, content and our service agreements for users in different languages. From English into Serbian, Bulgarian and Croatian. This article is about the task and its solution. Hope, this guide will be useful for you.

Us and multilingual end-user service docs

Our video service START (similar to Netflix, Hulu, Amazon Prime) offers a paid subscription model which provides users the access to certain content on our platform (web, apps, Smart TV). Like others, we have our own legal docs to clearly describe the rules that govern use of our service, how we collect the user data, apply promo codes and so on. Users from different countries watch movies on START, and step by step, we scale our presence in different states. In respect to legal docs, we need to:

• make the user experience more convenient,
• meet the requirements of the applicable laws,
• find the right way to manage the “papers” as easy as it is possible.

To do so, we had to translate our rules into different languages. We did it, and now, users receive our service’s agreements and policies on the corresponding language selected automatically: our system makes the selection based on the user device’s probable location (a country) and the device’s language. Let’s say if the user is in Bulgaria, he will get the Bulgarian versions of our documents. If the user moves to a different country he gets an access to the local one (if it’s available). START followed the Uber Legal model’s idea (thank you, guys!) when users get one agreement in English and it’s localized versions in different languages in which the particular provisions reflect the features of each of the jurisdictions.

Our software can identify the correct language based on the customer device’s geolocation data. For situations when our user is in another country we provide the option to switch the location manually. Besides, many prefer to use streaming services to learn foreign vocabulary and choose a language different from their native one. This choice is recognized at the user profile level, so viewers do not need any further actions. On the other hand, the previously selected language is applied automatically when the user switches to another application.

L10n of user agreements: the general points

The main points of departure for localization have just been indicated, but let’s look a little bit deeper and run through each point.

(a) User experience. No doubt, most of us like the interfaces, where all stuff and content are intuitively understandable and readable. The legal documents are not the exclusion. When you pay for something, you’d like the terms of the deal are clear, don’t you? Here is the same. We have own legal documents, users should know them. That’s not good when the language of the legal policies text differs from the user’s language. So, the service team should strive to provide proper documentation in a convenient form (in respect to its own documents too) and users will appreciate it, really. If you don’t agree, then ask your support team about it. They are the first who find out user problems on misunderstanding of your rules. And if your service rules have clear text on the right language for users, they will contact your support team much less often, and your colleagues rarely distract you. So, save your and colleagues’ business hours for more interesting things through improving the user experience.

(b) Requirements of the laws. Every state has its own consumer protection laws. For example,

Although their principles are relatively general, users should know what kind of service they are purchasing and under which conditions, its price, and term. Accordingly, the customers should be aware of their rights, they should be able to refuse the service on understandable terms. While localising user agreements, we took into account not just the translation of the text, but also the legislative features of the applicable country. Therefore, we developed one general document with information applicable for each country in English and separate specific local versions.

If you have a service agreement (main and actual version) in one language and an additional one localized version in another, do not forget to clarify in both, which document legally prevails in case of conflicts between them. Otherwise, you will meet the risk of having two separate agreements (e.g., in English and Bahasa Indonesia) and your team will rely on the English version, but disgruntled user (and his attorney) on another text unknown by your in-house lawyers and managers. Because previously you’ve just ordered the translation of your doc and none of your teammates know this language. And if that user is suing you for your service in a local court (referencing to the translation you hardly understand), just think about, what version of both your documents the court will consider and regard as applicable and binding. Keep it in mind. You can mitigate this risk by adding in both documents a provision about which document (in what language) is applied and prevail. Need examples? A lot of them. E.g., see them from Amazon (first sentence), Apple (section 12), Intel (clause 12.1) Maxim (section XIII), and our End-user agreement for Serbian users (first paragraph).

Denis Dorotenko, Legal Team Lead at START

Different states may have different rules in respect to personal data too. If a service collects and processes personal data, it should notify users of the rules for such collecting and processing (usually through its own privacy policy). A privacy policy describes how a service provider may process personal data when someone is using this service. It describes purposes, legal bases and retention periods of user data processing, rules to apply for international data transfers, use of cookies and similar technologies, marketing and PR activities based on user consent, etc. Of course, START have its own policies (e.g., this one) based on the requirements of the GDPR for users from the EEA. Meanwhile, we may use different policies for users outside these territories to collect and process their personal data.

As you already understood, localisation requires a lot of effort not just from the product perspective, but we also need to comply with the national laws for each particular case. So, we have external legal consultants who guide us through local requirements in different countries and we reflect their advices in our end-user documents.

(c) Manage the “papers”. Our service is designed to be used by users among different lands, so it is designed to scale. In respect to our documents, the task was the same — to design a simple, flexible and scalable solution of providing the documents for users. As indicated above, our development team followed the spirit of Uber Legal model. So, the users get the access to applicable documents and may read the texts in English (which prevail). But this is on the surface. What is the behind the curtain?

• Published archives. Each service should decide, whether it will be transparent or not, when updating end-user’s documents. If so, the service provides users with not only the latest version of service agreement, but the previous version (as archived) too. Through this approach one can see a service document’s evolution. It is appreciated by both users and regulatory authorities. We prefer to be transparent, so you can find our prior legal texts in the bottom of end-user agreements and policies (e. g. here). Many other services keep the ways to their prior texts as well: Corel, Stadia, Ubuntu, YouTube, Wikimedia Foundation.
• Inventory matrixes. That’s wonderful to have the legal texts for different jurisdictions and update them in time. But how to keep in mind, how large is your Candyland right now? We prefer to deploy the tables in Confluence. We indicate the following data for each our end-user document: a scope, version and status (current or archived), where it is available on the service, is it in the progress of updating or not (if so, in which ticket), where this version was approved, additional comments. It helps us to manage our agreements and policies, so they don’t get in a muddle.
• Files Storage. We shouldn’t forget about physical storage of our files containing the text of all our end-user legal documents. It would be awful, if we lost any of them and did not find it published on the service. So, our internal server kindly helps us to keep them safely. To avoid any unexpected surprises with it we have an alternative separated solution — upload files directly into Confluence and attach them to the matrix. This is a big part of our working time, but it helps us to mitigate the risk related to internal server and sudden loss of files.

Legal risks in the localization of end-user documents

Essentially, the service team faces several major risks when localising end-user agreement. There can be a danger of not complying with local laws and other legal requirements of the certain jurisdiction. If a web-service ignores some requirements or cannot satisfy them it can be forcibly blocked inside the country. As happened, for example, with Telegram in Russia, Indonesia and China or TikTok in India and Bangladesh.

First of all, a language of your service’s rules. A simple example: let’s imagine, your service is now available in Canada. Nice move! Now try to answer without googling: should your end-user documents for Canadian users be published in English, French, or both languages? Don’t you know? Hmm… Let’s find the answer at Apple:

If You are located in the province of Quebec, Canada or are a government organization within France, then the following clause applies to You: The parties hereby confirm that they have requested that this Agreement and all related documents be drafted in English. Les parties ont exigé que le présent contrat et tous les documents connexes soient rédigés en anglais.

Apple Developer Program License Agreement,
Section 14.11 “Entire Agreement; Governing Language”

Legalese in French? Parties confirm the request of all documents in English? Seems like a kind of some privilege for Quebec… What is all about? Let’s get it sorted out.

Quebec has a special Act respecting French, the official and common language of Québec (also known as Bill 96) and the Québec Charter of the French Language. In accordance with it:

Quebec contracts containing printed standard clauses or that are predetermined by one party must be in French unless the parties expressly request that they be in another language. Quebec consumer protection legislation similarly requires that consumer contracts be drawn up in French unless the parties agree to use another language. Parties wishing to contract in English may do so by including a clause expressly stating their consent to do so.

Canada: Languages of Business Overview
Stikeman Elliott LLP

So, we can conclude the following. Apple, having the business in Quebec and being obliged by these local laws, does not wish to translate and maintain dozens of its legal pages in French, just adds a couple of sentences in its end-user agreement in compliance with Quebec regulations — and voilà! they apply the English text only. This is just an example of local legal requirements related to a language of an end-user agreement! Not personal data, terms and costs of services and so on. Just the language!

The second and third major risks are related to breaking the laws on consumer data protection and personal data processing. The fines vary by jurisdiction. However, companies can lose thousands and millions of EUR.

Just some examples of fines imposed for violating the GDPR:

Our lawyers need to identify the risks in different jurisdictions and prioritize those possible dangers, saying if they are average, above average, or critical. Thereafter they contact the team to make a common decision of accepting or not accepting those risks and minimizing them as much as possible.

Let’s speak about next four aspects. First, the following issues may be different in other countries as usual: the ways of communication between users and a company; time to response on a user’s request; refunds; termination of an agreement.
Second, if you send documents to lawyers for review, it is recommended to make sure that lawyers understand your work model correctly.
Third, for translation of end-user documents, it is best to hire special translation agencies experienced in legal translations. They care on their reputation and hire good translators. However, translators can make incorrect translation of your company name, so you should double-check this after them. It may happen, for example, when translating into Armenian, Georgian, Arabic. You should have correct translations of your company in the languages you need, so that each document has one its correct name.
And finally, it is also a good idea to check the translation results — the main terms of your documents before publishing: essential conditions of an agreement; license conditions; methods of payments and refund terms. You can self-translate these clauses using online automatic translation services to ensure that important terms remain unchanged.

Nurguyana Tretyakova, Legal Counsel at START

How to prevent risks — a short guide for international multilingual services

Overall, a service rising and appearing into new markets or jurisdiction is an exciting, but responsible journey. And working on end-user legal documents is a part of it. Be ready for this. Of course, we made the mistakes too. But it is also a part of journey. And our experience we may summarize in the following short guide for you:

• Keep in mind local legal differences and features. If a company does not have the budget to hire in-house legal adviser or an external consultant, the gaps that remain in the end-user documents will emerge sooner or later, it’s just a matter of time. Try to find budget and order revising of your docs by local expert.
• Documents are becoming outdated. The laws are not static, many legislative bodies adopt acts so quickly as if they are in a car race. So, it is advisable to make revisions to the end-user agreements at least once a year and check for any changes in local laws.
• Do not forget on the refactoring. For many people the legal texts are just the “blahblahblah-yawn-small print”. A code and legal text have a lot in common: both of them are written to solve applied problems, in accordance with certain rules, most likely have a structure, and so on. As programmers remember their embarrassing code in past, lawyers remember their shame too. All we keep in mind the advantages of a code refactoring, but rarely apply them in respect to legal documents (therefore, the GDPR forces many of us to simplify the texts of our privacy policies). And localization is a good reason to review the structure and scope of your texts. Especially when your translators became expensive, because of your multi-page end-user policies.
• Think ahead about scaling of your service. Solve the issues keeping in mind the service’s possible scaling. The team has to develop a systematic approach toward user documents: developing agreements for 2 countries is not the same as having them for 15 jurisdictions and in 12 different languages.
• Save your own and your colleagues working time. As mentioned above, readable documents can really reduce the number of user requests about them and increase the level of respect to your service. Maybe it’s time to take the CDPR’s approach?
• Maintain your Candyland. You are that hero who just in seconds may answer what document is applicable for that land, what the differences between these two policies and where Rachel can take the right .docx to send it for a translation. Don’t let us down.
• Merge documents. Sometimes it is better and cost-effective to merge documents in the same language and highlight just some particular differences. TikTok’s Terms of Service is one of the best examples of this realisation. See the “Supplemental Terms — Jurisdiction-Specific” section: Brazil, India, Indonesia, Mexico, UAE, Turkey. Not the separate agreements with a lot of common rules, but just some paragraphs for certain jurisdictions. Briefly! Or you may merely form your documents like a layer cake, next text under the previous one as Bethesda does.
• Guerrilla translation. Not enough budget for lawyers and translators? Just keep in mind the automatic translators. By the way, are you an Atlassian products user? If so, that guys have already cared about you and your language skills, see their footer. This trick may help you to provide users with your agreements on their own languages, but it may not mitigate the corresponding legal risks. Keep it in mind!

For your convenience, these conclusions are also available to print, you can download them here.

That’s all. Thanks for reading. If you are just starting the path of legal translation or localization, good luck to you, mates.

#START, #Legal, #Localization, #Lacalizeuserdocuments, #userdocumentstranslation