Localization of Android applications using Google Sheets
I read the publication "Localization of Android applications using Google Sheets" and was surprised. A whole team (translator, developer, author) is working on the project, but one of the primary tasks, product translation, is inconvenient.
Paid services are good for everyone, except that they are paid. The translation involves many authors in their essence - and Google Doc immediately pops up as a convenient multi-user editor for one document.
I am a developer of a small but proud Android application. As soon as the third language was added to the project (after English and Russian), I immediately transferred the entire dictionary base to Google Spreadsheets . Immediately I felt the convenience of matching the multilingual strings - I had to adjust the length pretty. The first few times I transferred the translations manually to project resource xml files. Then he spat and wrote the usual parser: from the exported TSV Google Sheet file to a set of localization files, ready to be immediately added to the project.
')
Why Delphi? - it was more convenient for me, not so long ago I was picking up an old program for reformatting tricky files and for linear parsing of a text file into another. No extra files in the project.
Why TSV? - csv is not suitable because of collisions, if the lines contain commas ... and then did not look.
Since I am simultaneously developing two projects, and the second project is a more functional version, it seemed to me convenient to have a common vocabulary base for them. Sharing resources through markers - the first column in the table.
In the analysis there is nothing tricky. I export the file to a tab-delimited table, and in the parser I bring in data columns. The first, as I already mentioned, is service and has labels, how to handle a line:
The common line for the base project - universal for all localizations, is stored in the shared values / folder in string_common.xml
Unique string - unique for the language, fits into its localized folder values _ ** / strings.xml
In the comments to the opposing article I saw a question on the preparation of resources for different platforms. With a separate tool to bring Google Tables to resource files is not a problem, but the task for a free evening.
I am developing in Eclipse on Windows and it’s convenient for me to simply replace the localization files. The whole context of the translation is easily traced by the neighboring translations and the first columns - comments. The entire translation, and its more than 1000! strings performed by volunteers, grateful users. Each release of the program with an updated translation, whatever it was. For questions and suggestions for help with translation, I simply give a link to the table.
PS The project, as promised, combed and laid out on GitHub .
Paid services are good for everyone, except that they are paid. The translation involves many authors in their essence - and Google Doc immediately pops up as a convenient multi-user editor for one document.
I am a developer of a small but proud Android application. As soon as the third language was added to the project (after English and Russian), I immediately transferred the entire dictionary base to Google Spreadsheets . Immediately I felt the convenience of matching the multilingual strings - I had to adjust the length pretty. The first few times I transferred the translations manually to project resource xml files. Then he spat and wrote the usual parser: from the exported TSV Google Sheet file to a set of localization files, ready to be immediately added to the project.
')
Why Delphi? - it was more convenient for me, not so long ago I was picking up an old program for reformatting tricky files and for linear parsing of a text file into another. No extra files in the project.
Why TSV? - csv is not suitable because of collisions, if the lines contain commas ... and then did not look.
Since I am simultaneously developing two projects, and the second project is a more functional version, it seemed to me convenient to have a common vocabulary base for them. Sharing resources through markers - the first column in the table.
In the analysis there is nothing tricky. I export the file to a tab-delimited table, and in the parser I bring in data columns. The first, as I already mentioned, is service and has labels, how to handle a line:
- 0 - no, service information;
- 1 - language code, to replace the asterisks in values _ **;
- 2 - language code of the parent from which missing translations are taken, if specified; for example, for Belarusian and Ukrainian, this is Russian.
- 3 - the general line for the basic project;
- 4 - a unique line for the base project;
- 5 - a unique string for the project heir, overwriting the string with the same key of the base project;
- 6 - the general line for the project-successor;
- 7 - unique string for the project heir;
The common line for the base project - universal for all localizations, is stored in the shared values / folder in string_common.xml
Unique string - unique for the language, fits into its localized folder values _ ** / strings.xml
In the comments to the opposing article I saw a question on the preparation of resources for different platforms. With a separate tool to bring Google Tables to resource files is not a problem, but the task for a free evening.
I am developing in Eclipse on Windows and it’s convenient for me to simply replace the localization files. The whole context of the translation is easily traced by the neighboring translations and the first columns - comments. The entire translation, and its more than 1000! strings performed by volunteers, grateful users. Each release of the program with an updated translation, whatever it was. For questions and suggestions for help with translation, I simply give a link to the table.
PS The project, as promised, combed and laid out on GitHub .
Source: https://habr.com/ru/post/252969/
All Articles