0

situation:

  • we have multiple feature branches, one main branch;
  • one particular project has multiple XML files, key-value pairs for different languages;
  • only one person doing translation, not programmer, but an analyst;
  • we use feature branches to separate features and scope of testing; different QA is responsible for testing on different branch for different user story.
  • when a user story is done, we merge the feature branch up, and sync down to other sub branches
  • those language XML files are large, say, roughly a few hundred key-value pairs in each.

challenges:

challenges come when multiple feature branches need translation, and the translation changes are done in the same file, say Japanese;

  1. QA occasionally files a translation bug fixed in another branch;
  2. the analyst is confused which branch to work on;
  3. very high chance when merging, one version overwrites another version; because when we merge from a branch, the default logic in TFS takes the newer version to overwrite it. Most of time it works fine, but in some cases it failed, which increases the complexity of merging.

of course those challenges are manageable.

But ideally, I really think those static files should belong to one place instead of feature branches, so all feature branches share the same translation pack.

I could use an internal nuget source to host the language files, but it will increase the work every time we make a small translation change.

or I could setup TFS to use relative path, but then I need to update build definition in the build server and make sure the local build can grab the correct file.

Is there any other recommendation? Thanks

sowen
  • 1,090
  • 9
  • 28

1 Answers1

1

If you have any shared internal libraries then create NuGet packages should be a good way , and you can also create a vs solution just containing that library.

For XAML build, add a post build command to create the nuget package, or extend your tfs build template to do it (there's a number of templates out there that already do this).

For VNext build, there is a new VSTS Task called "NuGet Installer" this allows you to check in your NuGet.config file and specify the different package sources. Run this task before you run MSBuild. More details please refer: How to get TFS2015 Build (Build.vnext) and NuGet package restore to use custom package sources

Moreover, I think if your product or app haven't been published to user, the update changes of translation could not be so frequently. After all, just some translation and language packages. You could update it once or twice during an iteration.

Community
  • 1
  • 1
PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62
  • I agree that a nuget package is the best; however, you are right that this is in development stage; the challenge lands that we are docking an existing application to a different market with tons of different features, so the translation update is very frequent. Having a nuget package now will increase the load when updating it; after all, it's not the dev team updating it, but an analyst update the XML file. I will think about how to use a post build to auto package and deploy it. thanks – sowen Aug 11 '16 at 19:40