Making apps I have tried different translation tools, both on-premise and cloud versions, but I have been disappointed every time.
I mean, how hard can it be:
- I want to be able to create multiple projects for translation.
- I want to be able to translate the same project to multiple languages.
- I want to be able to import the source file.
- Then I want the tool to be able to translate automatically. However ridiculous the translations might be, most are actually ok.
- I want the translation to be free or maybe even to be able to access multiple APIs (to do).
- I want to be able to make project specific terms that might not be translatable to be inserted into the translated text.
- I want the tool to identify multiple instances of a phrase and translate all at once.
- I want to be able to import a translated file fully or partially and use my previous translation.
- And I want it to be simple and intuitive.
So, having checked a number of tools, I decided to make one myself. I have made an extension for Dynamics 365 Business Central, and not only that, I have made it Public Domain, so that everybody can help developing it.
You can find the beta on my public GitHub account:
It works like this:
- Import the AL Translation Tool extension in a Dynamics 365 Business Central Spring Release
Now the AL Translation Tool appears in the Departments menu or in the search
Start by setting up the module in the Setup page:
- The Default Source code language will be defaulted for all new projects and since the native language of Dynamics 365 Business Central is ENU, then that will always be the source.
- Use Free Google Translate API. The limitation is that it is only possible to access the API a limited number of times each hour. This is included because maybe someone wants to add other APIs later.
Project no. series like everywhere else in Dynamics 365 Business Central.
Next are the General Translation Terms that will apply to all projects. It can be a bit difficult because the translation tools tend to translate the same phrase with different words, so it is the translated word that must be included here. Another use could be to change field names that would be totally different in the different languages. The examples here are in Danish but it is clear that the translation has used different phrases for the same word.
Then it is necessary to add the Language ISO codes to the Language table:
Now it is time to create the first project:
I only add the name and the source language code. I can import the source from my extension already now, in this case I import the Manufacturing Plus.g.xlf file directly from my Dynamics 365 BC extension using the Import Source action:
It is possible to see the Translation Source by clicking the Translation Source action:
The left side are all the captions from the extension and the right side are the Developers Notes that was created by the AL extension in Visual Studio Code.
Reimporting the Translation Source will not delete the old source, but add any extra fields to the Translation Source and Target.
Then I go back to the project to create one Target Language for each language I want to translate to. I only need to add the language code:
In the Translation Terms page, it is possible to copy from the General Translation Terms:
It is also possible to add extra Translation Terms from this project to the General Translation Terms.
Back to the Target Language page, it is possible to access the Translation Target page:
Every time it is accessed, it will create all new Target translations from the Source file:
Here are two extra fields:
Translate: Mark this if the source should be included in the Translate All action.
After the automatic translation has been made the field will automatically be cleared. The Translate action ignores that and translates regardless.
Target: This will be the translation that can originate from either:
- The Google Translate
- Maybe combined with a Translation Term
- Or manual translation. On entering a manual translation for a source phrase with multiple instances, it is possible to confirm changing all instances at once.
Here is also an extra FactBox showing how many instances of the source phrase exists.
Using the Translate button, the Google Translate API will be called and the result will be validated against the project Translation Terms:
In some cases, the setup will be translated, but in this case, it didn’t and I need to translate it myself. Notice that it translated both the table and the page. The origin is noted in the Developers Notes FactBox:
Changing it manually, will give the following message:
And now it is correct.
Using the Translate All action, I firstly need to mark the lines I want to include, so I click Deselect All, mark a number of lines and click Select All:
And then click Translate All. I haven’t found the exact number of translations per hour but I think it’s around 30. Now let’s take a look at the result:
It is obvious that the Translation Terms has kicked in, and that a few terms are missing: purchase creditmemo, SKU, docking, so they need to be added to the terms, and I can mark the lines to rerun and then run the translation again:
And the result:
I can then export the translation file to a new .xlf file, in this case, the name will be:
And then include it in my AL extension project, recompile, publish and Install. The result is here:
It is obvious that I have made a partial translation. The fields marked in red was not included.
If I already have a full or partial translation file, then it is possible to import the file directly into the Target Language page:
A warning will be given:
Answering yes, the file is imported.
In this case, it was a full translation from previous:
Now I can keep working with this file and export it again.
It is possible to import translation files with on part of the solution translated.
Just now, the Developers Notes are not exported correctly. Anybody who wants to give it a shot, please contact me directly. The issues are described in the Issues List Word file.
So, download it, play with it and give me your comments.