Localizing Google Chrome Extensions - Necessary and Easy
The variety and easy availability of extensions have played a significant role in the popularity of the Google Chrome browser. Probably many of you have the experience of writing them. Perhaps not yet experience, but already a desire to try, or even a specific idea. It remains only to start.
Already at the design stage, I suggest you think about multilanguage. Most people are much more comfortable using the product in their own language, even if they know English, and especially if they do not know.
A lot of benefits for you: the potential audience will grow significantly, the number of installations will increase. You will receive an intriguing feedback:
')
In this post, I will talk about how I translated my extension “ Image in the Center ” into 11 languages, how I organized the process and what auxiliary tools I used to automate the boring routine.
The Google Chrome developer documentation details what you need to do to translate the interface of your extension or application into more than 50 languages. Do not worry, it is not necessary to translate to all 50, you can skip Vietnamese, or even leave a couple of popular ones, including Russian.
Distracted. In short, then:
The file is simple - it is a list of keys, each of which corresponds to a specific word, phrase, sentence, or whole story. For these keys, pieces of text will be taken from messages.json and added to the interface. Each of them carries three parts:
Unfortunately, the Chromium engine development group, which is the basis of Google Chrome, did not implement “pluralization” (declination of words depending on the numeral) at the level of the locale file structure. They can be understood. Due to the diversity of languages, due to the abundance of specific rules, it would be very difficult to make it. Instead, they propose to use ambiguous language, for example, “Number of available languages: 11” instead of “Translated into 11 languages” .
When you decide to add a translation to another language, you will need to create another directory, place the file there and carefully fill in the keys, as in the other fields, phrase by phrase.
But what if there is another button in the interface? It does not matter - we open each directory in succession, then each file, add a new key with the name of the button, write the translation, save it. So, stand, and add to the fr directory? Open the file, check, save ... And translated into Spanish? We open, check, save ...
And what if there are five new elements in the interface? What if ten? The likelihood of an error is very high.
Google has given developers quite good tools for internationalization, but in practice daily work with a bundle of files is inconvenient and boring. Even if you are willing to accept boredom, the human factor leaves a loophole for mistakes. Their probability must be reduced whenever possible.
How to improve the existing scheme?
Having decided that it is better to lose a day, and then in five minutes to fly, I began to search for a more convenient solution. I will not lie, I searched for a short time. Like any other developer, he quickly gave up and took hold of his bike.
The first thing that comes to mind is that it is much more convenient to store and edit phrases in one place, in one file. So that everything was immediately before my eyes.
The ideal format is the table. Columns correspond to languages, strings - keys with phrases. You can use any convenient editor: Microsoft Excel, Numbers from Apple, something else. I stopped at the tables from Google Docs. For example, a fragment of my only file now looks like this:
With such a table it is easy to add new languages ​​- copy the file and send it to the translator. He fills his column and sends back.
With such a table it is easy to add new phrases - we create a new line for the next key and consistently fill all the columns. You can adjust the backlighting of empty cells in the editor with an alarming orange color - now we will definitely not miss anything.
Placers are also added simply; you wrap the group in parentheses, you divide the key and value with a colon ( see example ).
Creating a structure, correspondence with translators, something on their own - the table is ready. What's next?
To generate all the necessary directories and files, I wrote the npm-module csv-locales . Its core is another, third-party utility csv-parse . The name does not lie, it parses the CSV file, converts it to json and sends the result to me. The CSV file itself is exported from our table. Further, the document is analyzed and divided into smaller fragments, into separate languages. They are in the form of messages.json placed in the target directories. Everything happens one to one, as I mentioned a little higher, but almost instantly and without mistakes ** laughter from the audience ** .
We will reduce our participation to a minimum, we will start the process with a single command from the console. I wrapped the module in plugins for two popular build systems:
All that is required is to export your file to CSV format and set a script on it. As a basis for the table we use this sample .
Configuration example for grunt:
Result:
Hooray! Adding new languages, new text elements to the interface no longer causes depression. Automation of the routine allows you to focus on the really important points, on more interesting tasks, without the boring “opened / edited / closed / repeated” .
It should be mentioned that the Google team offers to order the translation of your extension right from the developer’s toolbar. You just need to download the original message.json , select languages ​​and pay for the work of translators. I have not tried. This service appeared relatively recently, when I no longer needed it. Plus, the money will be much more expensive than freelance translators. If you have experience of such a translation, please tell us about it in the comments.
The standard solution for software localization is the gettext library. It is not used for Google Chrome extensions, however, gettext-parser already exists in npm, which means, if desired, we can implement support for PO files. What are not plans for the future?
For those who read to the end, useful links:
I will be glad to answer your questions, to hear feedback. Tell us about your experiences. What are you using? What advise me?
Already at the design stage, I suggest you think about multilanguage. Most people are much more comfortable using the product in their own language, even if they know English, and especially if they do not know.
A lot of benefits for you: the potential audience will grow significantly, the number of installations will increase. You will receive an intriguing feedback:
')
In this post, I will talk about how I translated my extension “ Image in the Center ” into 11 languages, how I organized the process and what auxiliary tools I used to automate the boring routine.
Documentation
The Google Chrome developer documentation details what you need to do to translate the interface of your extension or application into more than 50 languages. Do not worry, it is not necessary to translate to all 50, you can skip Vietnamese, or even leave a couple of popular ones, including Russian.
Distracted. In short, then:
- All translations are inside the _locales directory located in the project root.
- For each language inside _locales , a folder is created corresponding to the language identifier. For Russian ru , for English en and so on. Their full list is at the docks .
- Inside the directory with the name-locale is the file messages.json . Translation in it.
The file is simple - it is a list of keys, each of which corresponds to a specific word, phrase, sentence, or whole story. For these keys, pieces of text will be taken from messages.json and added to the interface. Each of them carries three parts:
- message - the same text for display on the screen, for which everything was started.
- description is auxiliary text that allows the translator to understand the context of using message . After all, depending on the situation, the same word can be translated in different ways. So “spit (narrow strip of land going from the coast)” will turn into “foreland” , and “spit (agricultural tool)” into “scythe” . The text in the description is optional, you can skip it.
- placeholders - an optional property that allows you to pass an arbitrary context to a phrase. For example, for Pasha, show the title “Hello, Pasha!” , And for Masha, “Hello, Masha!” . Details on the use of placeholders can be read in the appropriate section of the documentation .
Unfortunately, the Chromium engine development group, which is the basis of Google Chrome, did not implement “pluralization” (declination of words depending on the numeral) at the level of the locale file structure. They can be understood. Due to the diversity of languages, due to the abundance of specific rules, it would be very difficult to make it. Instead, they propose to use ambiguous language, for example, “Number of available languages: 11” instead of “Translated into 11 languages” .
When you decide to add a translation to another language, you will need to create another directory, place the file there and carefully fill in the keys, as in the other fields, phrase by phrase.
But what if there is another button in the interface? It does not matter - we open each directory in succession, then each file, add a new key with the name of the button, write the translation, save it. So, stand, and add to the fr directory? Open the file, check, save ... And translated into Spanish? We open, check, save ...
And what if there are five new elements in the interface? What if ten? The likelihood of an error is very high.
Google has given developers quite good tools for internationalization, but in practice daily work with a bundle of files is inconvenient and boring. Even if you are willing to accept boredom, the human factor leaves a loophole for mistakes. Their probability must be reduced whenever possible.
How to improve the existing scheme?
Optimization
Having decided that it is better to lose a day, and then in five minutes to fly, I began to search for a more convenient solution. I will not lie, I searched for a short time. Like any other developer, he quickly gave up and took hold of his bike.
The first thing that comes to mind is that it is much more convenient to store and edit phrases in one place, in one file. So that everything was immediately before my eyes.
The ideal format is the table. Columns correspond to languages, strings - keys with phrases. You can use any convenient editor: Microsoft Excel, Numbers from Apple, something else. I stopped at the tables from Google Docs. For example, a fragment of my only file now looks like this:
With such a table it is easy to add new languages ​​- copy the file and send it to the translator. He fills his column and sends back.
With such a table it is easy to add new phrases - we create a new line for the next key and consistently fill all the columns. You can adjust the backlighting of empty cells in the editor with an alarming orange color - now we will definitely not miss anything.
Placers are also added simply; you wrap the group in parentheses, you divide the key and value with a colon ( see example ).
Creating a structure, correspondence with translators, something on their own - the table is ready. What's next?
Automation
To generate all the necessary directories and files, I wrote the npm-module csv-locales . Its core is another, third-party utility csv-parse . The name does not lie, it parses the CSV file, converts it to json and sends the result to me. The CSV file itself is exported from our table. Further, the document is analyzed and divided into smaller fragments, into separate languages. They are in the form of messages.json placed in the target directories. Everything happens one to one, as I mentioned a little higher, but almost instantly and without mistakes ** laughter from the audience ** .
We will reduce our participation to a minimum, we will start the process with a single command from the console. I wrapped the module in plugins for two popular build systems:
All that is required is to export your file to CSV format and set a script on it. As a basis for the table we use this sample .
Configuration example for grunt:
module.exports = function (grunt) { grunt.initConfig({ csvLocales: { all: 'source/locales.csv', options: { dirPath: '_locales' } } }); grunt.loadNpmTasks('grunt-csv-locales'); }; Result:
Hooray! Adding new languages, new text elements to the interface no longer causes depression. Automation of the routine allows you to focus on the really important points, on more interesting tasks, without the boring “opened / edited / closed / repeated” .
It should be mentioned that the Google team offers to order the translation of your extension right from the developer’s toolbar. You just need to download the original message.json , select languages ​​and pay for the work of translators. I have not tried. This service appeared relatively recently, when I no longer needed it. Plus, the money will be much more expensive than freelance translators. If you have experience of such a translation, please tell us about it in the comments.
The standard solution for software localization is the gettext library. It is not used for Google Chrome extensions, however, gettext-parser already exists in npm, which means, if desired, we can implement support for PO files. What are not plans for the future?
For those who read to the end, useful links:
- grunt task
- gulp task
- underlying csv-locales module
- sample table structure
- Google Chrome documentation for translating extensions and applications to different languages
- funny gif with cat
I will be glad to answer your questions, to hear feedback. Tell us about your experiences. What are you using? What advise me?
Source: https://habr.com/ru/post/267501/
All Articles