Hello Community!
Before I reveal my Christmas present to you guys, I want to wish everyone a Merry Christmas!
It is the most wonderful time of the year… and I feel like playing Santa ?
Now why this present and what is the present?
To all developers out there, how do you manage the translation of your applications?
I guess it is not your most favorite part of the developing process, right?
To be honest it isn’t mine either. But those fewer favorite parts can be converted into fun! That’s right! Thanks to my colleague joachim.vanpraet we made the translating part interesting!
Joachim had the great idea to build a Node.js app to convert all our i18n.properties files to one CSV file. This together with a second feature to convert the CSV file back into the right translation files in the appropriate i18n directories.
What is in it for you?
It is a nice way to start building Node.js applications, it will help you in the future to save time when translating applications and it is a lot of fun!
Result => Happy team => Happy customers => Happy work!
During the build process of this application we will be using the following packages:
To get started with Node.js applications and the deployment to Cloud Foundry, you can get started right here:
Create a Node.js Application on Cloud Foundry
https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/772b45ce6c46492b908d4c985ad...
If you want to start developing the Node.js application immediately you can skip to my second blog:
Christmas ? Node.js I18n – CSV Converter – Part ??.
But I do recommend to have a look on the architecture and setup below.
The full code of this application can be found on my GitHub repository: Node.js-I18n---CSV-Converter.
Like I mentioned before there will be 2 main features in this Node application. The first one is creating one CSV with all the translations of every I18n file in your project. The second feature is converting the CSV data into the original I18n files in the appropriate app directories.
Now, let’s have a closer architectural look on how this conversion will work.
From Project to CSV
Whether you are building your application in the SAP WebIDE or locally, the Node.js application will be able to translate your files. Obviously if you export the MTA project from the WebIDE, you need to unzip it before passing it to the Node application.
Imagine we have the following MTA Project, which holds a Fiori Launchpad Module and an HTML5 Module.
The Fiori Launchpad Module holds two .properties files under the portal-site > i18n directory. The defaultCatalogId and the defaultGroupId properties files which looks like this:
When we have a look at the i18n.properies file in the HTML5 Module under the webapp > i18n directory we see that it has the following content:
When we tell our Node application to convert all the I18n.properties files of every single module (in this case the Fiori Launchpad and HTML5 Module) into a single CSV File, the result will look like this:
Since all the i18n files were the default translation files in the projects our result looks like the table above. Ordered by app name/Module, the key for the translation and the default translation. Since there were no other languages provided yet.
Now let’s duplicate the i18n file of the HTML5 Module and call it: i18n_en_US.properties.
The naming convention is: whatever_languageAbbrevation_COUNTRY.properties
Let us immediately repeat this step for the French language in France and Belgium.
After duplicating these i18n translation files, your HTML5 Module > webapp > i18n directory should look like this:
The default file and the English US file will contain the English translations obviously. French translations can be found in the French France and French Belgium translation files.
Next translate the files. For demo purpose I added the language in the sentence translation as text to make it clearer.
Default language (i18n.properties😞
English United States (i18n_en_US.properties😞
French France (i18n_fr_FR.properties😞
French Belgium (18n_fr_BE.properties😞
If we would run our Node.js App again at this point, we would see the following result:
(Time to zoom in guys)
Our earlier created translation files are arranged per module && key on a designated row with all the translations (=> all the files we provided). This way you can easily fill in all the translations for every app and you have a nice overview of where you are in the translation process.
The first column holds the reference to which application/module the translation belongs.
In the second column we have the key for our translation.
While in the third column the default translation is stored.
All the other columns are other translation files found in the modules.
From CSV to Project
Obviously creating this CSV File is “worthless” if we cannot transform the content from it into the original i18n.properties files.
To make the demo a little cooler, update the title of the HTML5 Module in French Belgium and write something in it. I will put “Mon titre en Français en Belgique”.
The file should look like this:
Let’s tell our Node application to convert the CSV file into the i18n files and have a look at the result:
As you can see the title key has been updated with the French value we just provided. Nice!
What happened? All the i18n files in the modules under our MTA project have been updated with the values from our CSV file. Even better is the fact that this conversion also provided the translation files for the other modules that were not holding other translation files yet. If you have a look at the Fiori Launchpad Module in the i18n directory, you will see that all the other languages were created too in the respective .properties files. As you can see the fr_be and en_US and other files were created and those were not there yet from the start.
The last cool feature in the conversion from the CSV file to i18n files is that when you add some languages in the CSV file manually, those files will also be added.
Let’s do this. I will add the language Italian as a new column, called it. I call it ‘it’ to show that you don’t even have to add the country code. As last I provide the Italian translation for “App description”. Which is "Descrizione dell'applicazione".
Time to run the Node app again and convert the CSV file back to i18n files.
Tadaaaa! Our Italian translation file was created, and the value was stored.
The file name is called i18n_it.properties.
Note: Depending on the editor you use to modify the CSV file, you might have to add the comma character at the end of every row when you added a column value like we did with the Italian “it” value. This obviously because it is a CSV file (Comma Separated Value).
We did not add translations for the other keys, so they are empty as expected.
With this architecture and features in the Node.js application, we can handle all our translations both ways. In creating the CSV file with all the translations and converting them back into the appropriate directory as i18n files.
So, what do you guy’s think? Cool tool, right? Time to make this happen! Let’s go over to the next blog to start developing this Node.js Application. Hands on time!
Christmas ? Node.js I18n – CSV Converter – Part ??
See you there and a Merry Christmas! ?
Kind regards,
Dries
Before I reveal my Christmas present to you guys, I want to wish everyone a Merry Christmas!
It is the most wonderful time of the year… and I feel like playing Santa ?
Now why this present and what is the present?
Introduction
To all developers out there, how do you manage the translation of your applications?
I guess it is not your most favorite part of the developing process, right?
To be honest it isn’t mine either. But those fewer favorite parts can be converted into fun! That’s right! Thanks to my colleague joachim.vanpraet we made the translating part interesting!
Joachim had the great idea to build a Node.js app to convert all our i18n.properties files to one CSV file. This together with a second feature to convert the CSV file back into the right translation files in the appropriate i18n directories.
What is in it for you?
It is a nice way to start building Node.js applications, it will help you in the future to save time when translating applications and it is a lot of fun!
Result => Happy team => Happy customers => Happy work!
Useful documentation, links and packages
During the build process of this application we will be using the following packages:
| Package | Documentation link |
| csvToJson | https://www.npmjs.com/package/csvtojson |
| properties-file | https://www.npmjs.com/package/properties-file |
| fs | https://nodejs.org/api/fs.html |
| recursive-readdir-async | https://www.npmjs.com/package/recursive-readdir-async |
| jsonexport | https://www.npmjs.com/package/jsonexport |
| properties-to-json | https://www.npmjs.com/package/properties-to-json |
| unicode-escape | https://www.npmjs.com/package/unicode-escape |
To get started with Node.js applications and the deployment to Cloud Foundry, you can get started right here:
Create a Node.js Application on Cloud Foundry
https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/772b45ce6c46492b908d4c985ad...
If you want to start developing the Node.js application immediately you can skip to my second blog:
Christmas ? Node.js I18n – CSV Converter – Part ??.
But I do recommend to have a look on the architecture and setup below.
The full code of this application can be found on my GitHub repository: Node.js-I18n---CSV-Converter.
The Architecture
Like I mentioned before there will be 2 main features in this Node application. The first one is creating one CSV with all the translations of every I18n file in your project. The second feature is converting the CSV data into the original I18n files in the appropriate app directories.
Now, let’s have a closer architectural look on how this conversion will work.
From Project to CSV
Whether you are building your application in the SAP WebIDE or locally, the Node.js application will be able to translate your files. Obviously if you export the MTA project from the WebIDE, you need to unzip it before passing it to the Node application.
Imagine we have the following MTA Project, which holds a Fiori Launchpad Module and an HTML5 Module.
The Fiori Launchpad Module holds two .properties files under the portal-site > i18n directory. The defaultCatalogId and the defaultGroupId properties files which looks like this:
When we have a look at the i18n.properies file in the HTML5 Module under the webapp > i18n directory we see that it has the following content:
When we tell our Node application to convert all the I18n.properties files of every single module (in this case the Fiori Launchpad and HTML5 Module) into a single CSV File, the result will look like this:
Since all the i18n files were the default translation files in the projects our result looks like the table above. Ordered by app name/Module, the key for the translation and the default translation. Since there were no other languages provided yet.
Now let’s duplicate the i18n file of the HTML5 Module and call it: i18n_en_US.properties.
The naming convention is: whatever_languageAbbrevation_COUNTRY.properties
Let us immediately repeat this step for the French language in France and Belgium.
After duplicating these i18n translation files, your HTML5 Module > webapp > i18n directory should look like this:
The default file and the English US file will contain the English translations obviously. French translations can be found in the French France and French Belgium translation files.
Next translate the files. For demo purpose I added the language in the sentence translation as text to make it clearer.
Default language (i18n.properties😞
English United States (i18n_en_US.properties😞
French France (i18n_fr_FR.properties😞
French Belgium (18n_fr_BE.properties😞
If we would run our Node.js App again at this point, we would see the following result:
(Time to zoom in guys)
Our earlier created translation files are arranged per module && key on a designated row with all the translations (=> all the files we provided). This way you can easily fill in all the translations for every app and you have a nice overview of where you are in the translation process.
The first column holds the reference to which application/module the translation belongs.
In the second column we have the key for our translation.
While in the third column the default translation is stored.
All the other columns are other translation files found in the modules.
From CSV to Project
Obviously creating this CSV File is “worthless” if we cannot transform the content from it into the original i18n.properties files.
To make the demo a little cooler, update the title of the HTML5 Module in French Belgium and write something in it. I will put “Mon titre en Français en Belgique”.
The file should look like this:
Let’s tell our Node application to convert the CSV file into the i18n files and have a look at the result:
As you can see the title key has been updated with the French value we just provided. Nice!
What happened? All the i18n files in the modules under our MTA project have been updated with the values from our CSV file. Even better is the fact that this conversion also provided the translation files for the other modules that were not holding other translation files yet. If you have a look at the Fiori Launchpad Module in the i18n directory, you will see that all the other languages were created too in the respective .properties files. As you can see the fr_be and en_US and other files were created and those were not there yet from the start.
The last cool feature in the conversion from the CSV file to i18n files is that when you add some languages in the CSV file manually, those files will also be added.
Let’s do this. I will add the language Italian as a new column, called it. I call it ‘it’ to show that you don’t even have to add the country code. As last I provide the Italian translation for “App description”. Which is "Descrizione dell'applicazione".
Time to run the Node app again and convert the CSV file back to i18n files.
Tadaaaa! Our Italian translation file was created, and the value was stored.
The file name is called i18n_it.properties.
Note: Depending on the editor you use to modify the CSV file, you might have to add the comma character at the end of every row when you added a column value like we did with the Italian “it” value. This obviously because it is a CSV file (Comma Separated Value).
We did not add translations for the other keys, so they are empty as expected.
Wrap Up ?
With this architecture and features in the Node.js application, we can handle all our translations both ways. In creating the CSV file with all the translations and converting them back into the appropriate directory as i18n files.
So, what do you guy’s think? Cool tool, right? Time to make this happen! Let’s go over to the next blog to start developing this Node.js Application. Hands on time!
Christmas ? Node.js I18n – CSV Converter – Part ??
See you there and a Merry Christmas! ?
Kind regards,
Dries
- SAP Managed Tags:
