Most of the companies I worked with didn’t really know who should own localization. Sometimes we would roll up to marketing, sometimes to product, sometimes to engineering, and sometimes to customer support. When I was at Lyft it seemed like there was a re-org every few months. This lack of stability and long term ownership causes uncertainty about everything from budgeting to QA.
My top recommendation is to rebrand localization as international or language experience. People outside of the localization industry don’t know what the term means, and it is also conflated with physical localization (which applies to autonomous vehicles). I use the term internationalization when talking to people outside the industry, since they understand what that means. Technically internationalization refers to things like date formatting, but for the purposes of communicating with prospects this works.
By rebranding the team, there will be less confusion about what you do. More importantly, this positions you as a strategic resource for the company whereas translation and localization is also viewed as an afterthought and as a cost center. When I was at Notion, almost 70% of our users were outside the United States, so management understood the importance of making the product work for users in other languages.
My experience has been that we got better resourcing, especially engineering support, if we were part of the product or engineering teams. The most valuable part of this is getting engineering support to address functional issues that translators can’t fix (database sort order, filters, layout problems, etc). These teams also have a growth mindset and are less likely to view you as a cost center.
This is particularly important in the early stages of building for international and language accessibility because companies will usually need to build out process automation, TMS integrations and often refactor their code to support multilingual operation. How long this will take will depend on how much tech debt the company has accrued. (At Lyft, it took nearly two years because they had a complex product that had assumptions about the US and English baked into so many different parts).
That doesn’t mean you can’t work on other customer touch points. It’s just better if you are part of these teams.
Several times I have reported to marketing. I have not really had a good experience with that for several reasons. The biggest problem with reporting to marketing is you will usually have little or no support from product or engineering. This means that design and functional issues will go unaddressed. What’s the point of translating your marketing site if it is going to drop the user into a broken experience? This will just get worse as companies build AI based products that don’t perform well outside of English and a handful of languages.
The other problem is that marketing teams will often throw stuff over the fence at you, often without considering whether a campaign will even work in a given country. Some campaigns can’t be translated easily, or have a call to action that makes no sense in other languages.
<aside> 👉
A pet peeve of mine with regional marketing teams is that salespeople will often assume they are translation experts. They usually aren’t, and often don’t understand that if the source material doesn’t work in France, there might not be a good way to translate it.
</aside>
These days I advise marketing teams to own creating and adapting campaigns. The centralized internationalization team can help them by providing and managing translation infrastructure. Translation is just one part of creating campaigns that resonate with global audiences.
Generally what marketing teams should do is to engage with agencies that know how to create campaigns for the target market. The internationalization team can onboard them to the translation management platforms, so the work can be managed centrally, but otherwise the marketing team will manage those vendors and their deliverables. The team can certainly provide advice and help in reviewing agency proposals.
This also insures that the teams are aligned. This is important because it keeps you out of the position of being blamed for a campaign that did poorly because it wasn’t culturally adapted (which needs to be addressed before any translation work is done).
One of the main goals for the team is usually to insure that most customer touch points are accessible in other languages. This involves implementing integrations with other systems including content management systems, help center, life cycle communications, videos, and so on. This is another reason why it is important to have engineering support because sometimes you will need to build custom integrations if your TMS doesn’t provide one. Ideally, you want to be involved in the discussions around choosing these systems, to insure that multilingual support and TMS compatibility is taken into consideration. Unfortunately, these decisions are often made long before internationalization is kicked off.
When I go into a company, I like to automate as much as possible, with the goal of making translation happen by default. That doesn’t mean using machine translation for everything. For example, if someone adds or updates a help center article, it gets picked up for translation without the author needing to make a request. This is a scalable approach and frees up the team’s time to focus on prioritization versus shipping files and spreadsheets back and forth.
Legal teams will generally want to use a translation agency that focuses on legal translation, contracts, etc. You definitely don’t want to send this material to generalist translators. They usually have preferred vendors, or will have their law firm handle this for them (which is usually expensive, but then again, most lawyers are expensive).