Easy BAML is not a completly new way of implementing localization. Rather it is revised and automated process of using approach, similar to MS LocBaml.

Table below describes difference between these two approaches.

(Perhaps comparation is not fully fair, because LocBaml is stated to be "not a production-ready application". But since so many people try to apply it "as is", this table can demonstrate both similarity and differences of both approaches, and simplification from using Easy Baml.)

Localization process step LocBaml procedure Easy Baml procedure
1. Update project file with property <UICulture>

Manually modify each localizable project file in text editor.

If solution is under source control, not forget to check out files for editing.

Automatically performed by addin during solution configuration, for all localizable projects at once.

If solution is under source control, files will be check out for editing automatically.

2. Set/update assembly NeutralResourcesLanguage attribute. Manually edit AssemblyInfo.cs or AssemblyInfo.vb in each localizable project in solution. Automatically performed by addin during solution configuration, for all localizable projects at once.
3. Add Uids to your XAML files.

Start VS command prompt and perform command "msbuild /t:updateuid helloapp.csproj" for each localizable project in solution.

If solution is under source control, not forget to check out all XAML files for editing.

In all XAML elements Uid will be set, even if element is not localizable.

Uid are generated as <ClassName>_<index>(e.g. TextBox_1, TextBox_2).

Performed from VS by "Prepare Translation" addin function, for all localizable projects at once.

If solution is under source control, files will be check out for editing automatically if needed.

Only for XAML elements that contains localizable properties Uid will be set.

Uid are generated as <ClassName>_<StringPart>(e.g. TextBox_FirstName, TextBox_LastName).

 

4. Parse sattelite assemblies to extract translation files Copy LocBaml.exe to your application's bin\debug folder, where the main application assembly was created. 

From command prompt use the following command:

LocBaml.exe /parse en-US/HelloApp.resources.dll /out:Hello.csv

Must be repeated for each localizable project (assembly) in solution.

Performed from VS by "Prepare Translation" addin function, for all localizable projects at once.
5. Translation files

Localizable content extracted into CSV files.

CSV files could be edited in text editor or e.g. in Excel.

CSV files contains all control's properties, but only few of them are actually localizable.

CSV file may not correctly handle line breaks inside localizable strings.

Generated CSV files should be manually merged with translated culture-specific CSV files.

Localizable content extracted into RESX files (please don't confuse - they are not embeded into assembly).

RESX files could be edited in VS or 3rd party translation tools.

(Translation by RESX files is standard de-facto since WinForms.) 

RESX files contains only control's properties, that are actually localizable.

RESX file correctly handles line breaks inside localizable strings.

RESX files automatically merged with translated culture-specific files.

6. Localization comments Supported, goes into column in CSV file. Not supported at the time.
7. Generate new .resources.dll files

Use the following syntax to generate a new HelloApp.resources.dll file. Mark the culture as en-US (/cul:en-US).

LocBaml.exe /generate en-US/HelloApp.resources.dll /trans:Hello.csv /out:c:\ /cul:en-US

 In the same assembly as the main application assembly, create a new culture-specific folder to house the new satellite assembly. For French-Canadian, the folder would be fr-CA. Copy the generated satellite assembly to the new folder.

These steps should be repeated for each localizable assembly in solution and for each supoorted culture,

Automatically generated with each build.
8. Windows resources in RESX files No out-of-box support. Linker AL.EXE should be used to link generated and compiled sattelite assemblies. Automatically fully supported.
9. Assembly and manifest signing No out-of-box support. Linker AL.EXE should be used to sign generated assemblies. Automatically fully supported.
10. TFS Build support No out-of-box support. Automatically fully supported.

Last edited Jul 5, 2011 at 9:40 PM by skiba_k, version 1

Comments

No comments yet.