|
Infralution Support Support groups for Infralution products
|
View previous topic :: View next topic |
Author |
Message |
TomClement
Joined: 22 Oct 2009 Posts: 8
|
Posted: Tue Oct 27, 2009 2:59 am Post subject: Steps for interacting with a localization vendor |
|
|
Hi again,
I'm still evaluating this product for use in an upcoming release. We are working with an existing localization vendor who uses their own tools (including translation memory). I have a couple of technical questions that I will ask in another post, but I wanted to understand the details of the workflow that you would recommend to use with your product for interacting with an external vendor. For example:
1. We create a globalizer workspace for the .NET Solution.
2. We run commands <x> to export a localization kit.
3. We send the localization kit to the vendor.
4. The vendor obtains all the .resx files from the kit, runs them through their translation memory and tools and generates .ja.resx files with translations.
5. The vendor uses the translated resx files with the localizer version of Globalizer.NET to generate Japanese satellite resources.
6. The vendor (who has an installed version of our product) does linguistic testing, finds linguistic bugs, fixes them in the .resx, and repeats step 5.
7. The vendor returns the translated .resx files to us.
8. We import them into Globalizer.NET.
9. We use the Globalizer.NET feature to update our Visual Studio solution with all the (almost 900) .ja.resx files.
10. We do functional testing with the translated locale (ja).
11. We identify new or changed strings in the English resources by comparing them with the previous .resx files given to the vendor (using Beyond Compare with a resx preprocessor), an internal tool, or Globalizer.NET if it supports this functionality.
12. We rescan the solution using Globalizer.NET?
13. We export and send the localization kit to the vendor and repeat until we're done.
I'm not sure exactly how all of this would work with Globalizer.NET (i.e. if it would support this approach) or whether there is a better way to use the product. One aspect of this is that I know our vendor has their own tools for doing the resource translations.
This scenario also assumes a certain amount of parallel activity between the developers of the base product (mostly bug fixes at this stage) and the work of the translator, hence the need for detecting changes to the resources as compared to a previous turnover.
Anyway, sorry for the length of the post. Just trying to deeply understand how we would use this product best in a large localization task with over 18000 strings.
Thanks again,
Tom |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Tue Oct 27, 2009 6:48 am Post subject: |
|
|
The normal process with Globalizer.NET is:
1. Developer creates Globalizer.NET Workspace, adds Targets for Visual Studio Projects and scans the projects for localizable resources
2. Developer exports languages to be translated to a separate workspace file and sends this exported workspace plus an installer for their application to the translator.
3. Translator opens the Workspace (in the free Translator Edition of Globalizer.NET) and translates the resources. They can preview forms/controls as well as build the localized resource assemblies so they can run and verify the localized application (see note below)
4. Translator sends translated workspace back to developer.
5. Developer imports translations from Translated Workspace back into the original workspace.
6. Developer builds the localized application - this build can either be a source localization (in which case you use Visual Studio to actually build the satellite assemblies) or a binary localization (in which case Globalizer.NET builds the satellite assemblies directly just like for the translator).
Globalizer.NET tracks the status and version of each translation item in each language. So if, for instance, you change the invariant text for an item and rescan the workspace after sending the translator the workspace to translate Globalizer.NET will handle this and when the translations are imported back from the translator the item status will be flagged as "Needs Review".
Note: For the translator to be able to preview forms/controls and build the satellite assemblies the developer must set the Deploy Directory for the workspace (and project Targets if they are deployed in different directories) to the directory that their application binaries are installed to. _________________ Infralution Support |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|