View previous topic :: View next topic |
Author |
Message |
divanov
Joined: 07 Oct 2013 Posts: 3
|
Posted: Mon Oct 07, 2013 5:03 pm Post subject: Central Resource Location |
|
|
I am currently trialing out Globalizer and loving the potential, but a big deal breaker for me is the fact that it seems to create a resource file for each individual control in WPF.
And a lot of the text is identical across all controls so it turns out looking something like this:
Is there any way to merge these fields and have a single resource location instead of having hundreds of resource files for every control?
And is there a comprehensive tutorial/manual on using Globalizer? I've tried using the built in help but it is extremely basic. |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Tue Oct 08, 2013 6:42 am Post subject: |
|
|
The use of separate resource files for each control is fairly standard practice for localization. This is also the way that Microsoft implemented localization for Windows Forms. There are three main reasons:
1. The same string in English may need to be translated as a different string in another language. For instance you may use "Code" in one place to mean "software code" and in another to mean "serial no". These may need to be translated differently depending on context.
2. Localizing the resource associated with a control into a separate resx file means it is easy to identify which resources belong to which control. If for instance you remove a form or control from your project it is easy to identify the resources that no longer require translation.
3. It reduces cross dependencies in your project. If you use a single resx file it is more difficult to have multiple developers working on the project because all are likely to be changing the same resx file.
Globalizer can automatically translate duplicate entries - so the use of separate resources does not add to the number of actual translations required - but leaves you with the flexibility described above.
If you have specific questions that aren't answered in the help then these forums are a good place to start. _________________ Infralution Support |
|
Back to top |
|
|
divanov
Joined: 07 Oct 2013 Posts: 3
|
Posted: Tue Oct 08, 2013 2:12 pm Post subject: |
|
|
Well since the functionality to edit duplicates exists that's good enough for me! And I can agree on the validity of all other points.
And what is the proper way of handling the GXL files with source control? Do they play nice with merging since it seems to be XML on the inside? How severe are merge conflicts? |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Tue Oct 08, 2013 9:03 pm Post subject: |
|
|
Yes the GXL files are just XML and so you can source control them and generally normal merges work without problems. If you have really major changes to a visual studio project/solution and then try to merge the corresponding Globalizer files then you may end up with conflicts. While it is not too hard to resolve these by hand it can be easier just to take the gxl file from one branch being merged and then rescan the merged project. Any translations can then be Imported from the other branch. _________________ Infralution Support |
|
Back to top |
|
|
divanov
Joined: 07 Oct 2013 Posts: 3
|
Posted: Wed Oct 09, 2013 7:57 am Post subject: |
|
|
Infralution wrote: | Yes the GXL files are just XML and so you can source control them and generally normal merges work without problems. If you have really major changes to a visual studio project/solution and then try to merge the corresponding Globalizer files then you may end up with conflicts. While it is not too hard to resolve these by hand it can be easier just to take the gxl file from one branch being merged and then rescan the merged project. Any translations can then be Imported from the other branch. |
Well that answers all of my questions, thanks for the great support! And expect an order! |
|
Back to top |
|
|
|