Localisation for non-English speaking countries, mainly in Asia
Localisation
Language support is very important to increase Sales in Asia. Language support means not only literal language but combining with culture and customs.
Product localisation
There are very good local communities who contribute their translation skills in CN,JP and KR (of cause other countries). This is very important and variable GitLab resources in those countries.
- GJ Suggestion: We should keep them and find out a better way to encourging them if there are less activities.
Documentation localisation - User manual, admin guides and other technical docs.
It seems to be a very important thing and everyone think we should have technical docs in local language. However, it is almost impossible to maintain our fast updating docs with those language. It must costs a lot and the ROI wouldn’t be good.
Although we (not only gitlab but other tools as well) do not have local language manuals but there are many users and contributors in those countries already. So that technical documents may not be that much important for engineers who has an experience, but for engineers who doesn't know about DevOps and GitLab well, some local language tech articles would be very helpful.
- GJ Suggestion: Hiring local language technical engineers more and ask them to write blog articles in local language. An example, https://about.gitlab.com/blog/kr, https://about.gitlab.com/blog/cn and https://about.gitlab.com/blog/jp.
Web site (Marketing purpose)
This can be combined with the local language blog suggestion.
A great approach for marketing purpose. Translate product introduction, case studies, comparisons pages into local language. Doesn't need to be whole pages but first a couple of pages would be good enough. Please have a look at the www.gitlab.jp. Creationline maintains and they get many leads from here.
However, if there is no local language speaking sales managers or XDRs, there is no point to follow them up. Who connects those local websites are mostly not comfortable with English. The lead follow up should be their local language rather than English.
- GJ Suggestion: Hiring local language speaking people (sales & tech) first. If our current resellers are willing to this, it would be also good but can be a conflict with local GitLabbers, need to communicate with resellers well.
Tech support
Finding bi-lingual technical resources is very hard and experienced bi-lingual technical engineers are looking for higher position, such as management, SA and TAM.
Also, most our customers who contact us with technical issues can read English. The problem is they are too shy to speak and write English. From my experiences, accepting local language technical questions in local language and answering back to them in English would be a good approach. The reason is that those engineers can improve their English communication skills by this email exchanges and this is the thing that most of them are willing to improve.
- GJ Suggestion: Local language speaking tech support engineers can translate the initial email but replying should be in English. So that we do not need senior level bi-lingual support engineers and those support tickets can be shared with other support engineers.
miscellaneous facts
Local Human resources
I can see many enterprises are still not comfortable to speak sensitive business information in online meeting although there is no literal language barior. Also, many of them are still demanding onsite demo, technical discussion and technical support.
Community members
The most important matter in this area and this is a significant difference from other tools. I only experienced Japanese and Korean communities via meetups but this must be not very different in other non-English speaking countries especially in China.
They are gathering offline meetups very actively and the first reason is language. Most of them (community members) can read English but the level of understanding can be different. It is very hard and time consuming work to read English.
If GitLab can provide documents in their language that would be the best but again it is not possible to maintain without a huge investment. Also, other tools are not providing local language manual. Opensource s/w is better in this point against closed source commercial s/w.)
- GJ suggestion: Invest to the way of expending community and aprising community members. This eventually will affect to boost localisation not only product but marketing and sales as well.
Resellers
Resellers have their own business plan and model. We must respect their business. We cannot push them to invest their money and resources into the localisation without a compensation.
However Creationline, Japanese reseller are maintaining www.gitlab.jp and generating some leads. I don't see any similar cases from other resellers yet. They also highly involved in the GitLab open source community. This can be a good case study to other resellers in non-English speaking countries.
Most of our current resellers are small and they are more like a human resource dispatching (providing consulting) company. Their business model is sending engineers to enterprise customers for integrating and operating between tools. This business model works well last 10+ years because there are many tools and changes, also most of those tools are in English. Customers do not need to spend their time to learn those new changes in English but hiring experienced engineers from those reselling companies in a short period of time. Those business model is conflicted with DevOps. Also, GitLab has many things in it already, don’t need that much integration.
-
GJ Suggestion: We need a different approach on reselling or partnership. Need to look for a large SI local companies who have enough resources to maintain cloud environment by themselves, such as Fujitsu, Hitachi and LG.
-
Please do not mis-understand me that I am not talking about we can ignore our current resellers, they are very important resources for selling more licenses and connect to local enterprise customers, they have very good relationship with local enterprises. We have to have a good relationship with current resellers but at the same time, we must find the way to get a higher level of partnership with large local SI companies.