Infralution Support Forum Index Infralution Support
Support groups for Infralution products
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Steps for interacting with a localization vendor

 
Post new topic   Reply to topic    Infralution Support Forum Index -> Globalizer Support
View previous topic :: View next topic  
Author Message
TomClement



Joined: 22 Oct 2009
Posts: 8

PostPosted: Tue Oct 27, 2009 2:59 am    Post subject: Steps for interacting with a localization vendor Reply with quote

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
View user's profile Send private message
Infralution



Joined: 28 Feb 2005
Posts: 5027

PostPosted: Tue Oct 27, 2009 6:48 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    Infralution Support Forum Index -> Globalizer Support All times are GMT
Page 1 of 1

 
Jump to:  
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