Category: Localization

This is the third in my series of posts on the GlobalSight Web Services API. See below for the previous posts:

• Interacting with the GlobalSight Web Services API from C#
• GlobalSight Web Services API: Automate Translation Memory Upload

In this post, I’m going to cover how to actually create jobs in the GlobalSight system via the Web Services API. Creating jobs via the user interface works fine, but if you want to automate the process, this is fully supported via the API. This can be useful if for example you wanted to create a better experience for creating jobs, or a totally different interface – useful if you have people not experienced with GlobalSight who may want to submit content translation or review jobs.

I’ll assume you’re all setup to interact with the API from C# (see the first post above for a basic introduction if you are not).

There are a couple of API calls relevant to job creation:

• getFileProfileInfo – This returns the list of File Profiles currently available in the system. The response is XML format, listing all File Profiles available in the system, each having an ID, Name and Description. The File Profile is a required parmeter to both the uploadFile and createJob functions.
• uploadFile – This facilitates upload of a single file to GlobalSight (note it does not actually create a job). This needs to be called once per file.
• getUniqueJobName – This function essentially takes a job name, and adds a nine digit unique ID to the name. Each job in GlobalSight must have a unique name. If you already have some unique identifier in your job name, you will not need to call this function, but otherwise it is useful for ensuring that there aren’t any clashes between job names.
• createJob – This is the function that actually creates the job in GlobalSight.

Let’s look at some simple code for job creation using the above listed functions.

			GS_API.AmbassadorService client = new GS_API.AmbassadorService();

			string jobName = "Demo Job (Ignore)";
			string textFilePath = @"C:\Users\Jimmy\Desktop\strings.txt";
			string fileProfileID = "37";
			byte[] fileContents = System.IO.File.ReadAllBytes(textFilePath);

			// Authenticate
			string auth = client.login("TestUser1", "password");

			// Here you would get the file profiles, and find the apt. one for this job
			// I'll leave this to the reader as an exercise, I've assigned a variable above

			// Next, lets ensure uniqueness of our job name
			string uniqueJobName = client.getUniqueJobName(auth, jobName);

			// Upload the file
			client.uploadFile(auth, uniqueJobName, "/files/strings.txt", fileProfileID, fileContents);

			// Create the Job - ensure to use the same job name as your call the uploadFile
			client.createJob(auth, uniqueJobName, "Demo Job", "/files/strings.txt", fileProfileID, "");

A couple of points to note:

• Each file you upload needs to be converted to a byte array. C# provides the handy function I’ve used above for this purpose.
• The third parameter to uploadFile, (in this case ‘files/strings.txt‘), is the location to upload the file on the GlobalSight server. There are a few folders created by default for any job, the language code, ‘webservice‘ which indicates the files were uploaded via the API, and a folder named after the job ID. The parameter above is the directory structure inside the job ID folder, this is whatever you want it to be. This is useful, as the files are exported in that same structure post translation, so you can for example retain the directory structure of a translation kit if you so wish. Here’s an example of how the file we uploaded above is stored on the GlobalSight server:

 

• The job name you pass to createJob, must be identical to the one you passed to uploadFile. This is how GlobalSight knows which files relate to this job.
• The final parameter in createJob is the target languages. Leave this empty (as I have above) and GlobalSight will assign all the languages contained in the Localization Profile that is associated with the File Profile you have specified.

That’s it, after you have run the above code, your job is now created in GlobalSight.

This was a very basic introduction to job creation in GlobalSight, showing how a single file can be submitted via the web services API.

I haven’t covered items such as error handling, or even creating jobs that have multiple files, not just one as in my simple example above – I will perhaps cover this in a future post.

GlobalSight is an open source Globalization Management System (GMS). It’s main purpose is to automate the flow of content to translators, and essentially streamline many of the tasks involved in the translation workflow, scoping, project management, translation, review etc. as well as centralizing translation memories.

Similar GMS systems would be SDL WorldServer (formally Idiom WorldServer before being acquired by SDL in 2008), and SDL TMS.

What differentiates GlobalSight (owned by WeLocalize), is that it is open source. The source code is freely available. It can be customized as you see fit. It also provides a very powerful web services API, that you can use to integrate other systems in your translation workflow with GlobalSight, that’s what I want to introduce here, specifically the steps to get setup from C# to interact with this API.

I’m going to assume you already have an instance of GlobalSight setup, I’d imagine you wouldn’t be interested in this API otherwise.

Setup Steps

• First off, create a new C# Visual Studio project, a console application will suffice for this tutorial.
• Next, we need to add a Service Reference to the API. To do this, follow the steps here, using the following URL:

https://<YOUR_SERVER_URL/globalsight/services/AmbassadorWebService?wsdl

Note – The service is called ‘AmbassadorWebService‘ because GlobalSight itself was previously called Ambassador, when it was owned by a company called GlobalSight. The product was renamed GlobalSight after it was taken over by WeLocalize. If you get to the point where you are looking at the (rather large) code base, you will see it littered with references to Ambassador.

• Once you successfully add the service reference, try to build your project – you will notice it will fail (at time of writing at least anyway):

There are duplicate entries in Reference.cs for these two functions, getAttributesByJobId and getProjectIdByFileProfileId.

To fix this issue, just double click on each of the above errors, and comment out the duplicate entries in Reference.cs. This will allow your project to build, but is a pain, as you need to do it each time you update your service reference.

Now that your project successfully builds, you are ready to use the API.

Authentication

Before trying to authenticate with the web service, you may need to do some manual configuration on your GlobalSight instance. The IP Filter feature is enabled by default – this will only allow IP’s on a white list to interact with GlobalSight via the API. There are two options here:

• Disable the IP filter completely – not recommended.
• Add the necessary IP ranges to the white list.

See the ‘IP Filter’ section of the web services documentation for more information on this.

Once you complete the above, we should be able to connect to the API via some C# code.

Before calling any operations, the login function must be called with a valid GlobalSight account. This function returns an authentication token which must then be passed as a parameter to all subsequent API calls.

Let’s connect, and call a simple function, getAllUsers, that will give us the list of all user currently in the system, and write it out to the console so that we can see the response:

GS_API.AmbassadorService client = new GS_API.AmbassadorService();

string auth = client.login("TestUser1", "password");
string userinfo = client.getAllUsers(auth);
Console.WriteLine(userinfo);
Console.ReadLine();

If you have done everything correctly, you will see an XML response in your console window detailing all the users currently setup in the system. Most API calls to retrieve information return an XML response, it’s just a matter of parsing it, and doing whatever you want with it then.

Conclusion

Here are my feelings so far, having used this API for the past 3 months to automate different tasks:

• You can’t rely on the documentation on the Wiki – some function definitions are out of date, some now have extra parameters etc. There is not enough information in the documentation about what each call actually returns (i.e. the format of the XML). I found myself having to run commands to see what they actually return. The API documentation needs some love.
• Some API call sequences (e.g. for job creation) are really difficult to figure out, e.g. you need to call uploadFile, then createJob. Again, making this clear in the documentation would be better.
• Some functions expect paramters in XML format, but no example of this format is give. Documentation!
• For an open source project, there doesn’t seem to be any community. The forums on globalsight.com are not particularly active, and run some really old forum software that is extremely frustrating to use. Maybe there is a community, and I’m just not aware, but it certainly looks like they don’t hang out at globalsight.com.
• All this aside, the web services API is extremely powerful, and I seriously recommend looking into it if you use GlobalSight – some functions can save you days – e.g. upload of translation memories via the API, as opposed the web interface.

This covered a basic introduction to interacting with the GlobalSight web services API from C#.

In a future post, I’ll cover how to actually create GlobalSight jobs via this API. If there’s anything else you’d like to see covered in a future post, leave a comment below, and I’ll see what I can do.