Well - sort of... we've named this version 4 because we had to introduce some changes that break the backward compatibility with version 3.
You can of course open older project files with BabelEdit 4 - they are converted to the new format automatically - but you can't open the new files with older BabelEdits.
Here's an overview over the most important changes
One of the most requested features by our customers is the support for multiple sets of translation files within a single BabelEdit project.
This is useful for translating 3rd party components and to make your application modular.
E.g. Laravel uses this a
vendor folder in the main translation folder to override translations
for 3rd party packages.
When opening an existing project, you should not see any differences compared to BabelEdit 3.
The package support is either activated by dragging and dropping some new language files onto the left panel of BabelEdit, or by using the Languages dialog:
You should see the following dialog if you drop langauge files onto BabelEdit's left panel or inside the Configure Languages dialog:
Check the language to file association and set the package name.
If you click on Add package you also have to set the package name. After that assign the files to the languages by clicking on the folder icon or by dropping language files onto the package:
After adding the first package, the new box icons appear in the tree view in the left panel.
BabelEdit can now display translations in a tree structure. For this, you have to
_ inside your translation IDs. E.g.
To enable the tree view click on Settings and switch the Format to ARB JSON with "_" as namespace delimiter..
BabelEdit tries to build the tree from that structure. You'll receive an error if this is not possible - e.g. Conflicting translation IDs: main_form.
This means that you have one ID that is part of another ID. E.g.
The first ID would create leaf inside the tree - whereas the same ID would be a branch for the 2nd ID.
To solve this, you have to rename the
main_form to something like
main_form_label. Try again to
switch the format after fixing the conflicting IDs.
Pre-Translate does not overwrite existing translations by default - to prevent overwriting manually edited IDs. The disadvantage is that, after editing your primary language, you'll have to delete the other translations if you want them re-translated.
The new Overwrite existing translations now requests a new translation for all entries from the translation service.
BabelEdit 4 now supports Arrays for i18next files. Simply name all entries with incrementing numbers starting from zero: 0, 1, 2, 3, ...
These values are now stored in a JSON array instead of an object.
Sorry to say so - but we had to drop the support for the
<i18n> sections in the .vue single
file component files.
The changes introduced through the Package support required some bigger
changes in BabelEdit's internal structures. Adding the .vue file support back in would
have created a too big overhead - especially since less than 1% of the customers are using
the single file components at all.
Using translations inside the .vue files is - in my opinion - a bad idea anyways. See Why using i18n sections in vue.js single file components is a bad idea.
Users who wish to migrate to .json files instead can follow the instructions in my tutorial here:
Please be aware that you need BabelEdit 3.0.1 to follow the tutorial.
If you absolutely can't switch from .vue files to .json files you'll have to stay on BabelEdit 3.
We've added a bunch of new languages to pre-translate: