How can you be sure your customer has purchased language packs?
Check the customer’s Schedule A which shows the licenses, languages, and other services from SF. You must be sure languages are purchased before you turn them on in provisioning.
Who implements language packs, SF or Partners?
Partners or SF PS both can implement language packs. It is simply a matter of turning on the appropriate languages in provisioning including the top checkbox for Language Packs. New instances already have that checkbox ‘Language Packs’, but that wasn’t always the case. And it will wreak havoc in your instance if that is not checked. Don’t ever uncheck it even if the customer only has English!
The key is to KNOW for sure the customer owns the language pack within their Schedule A or ask them to purchase before you turn on languages in provisioning.
If a customer purchases one language pack, then decides they want to change it, can you do this on your own in provisioning?
You should not just allow a customer to switch a language without a change order to their contract. This would be handled through their SuccessFactors Account Exec and then have them show you the change order. Only at that point would you change the language in provisioning.
Which default language does a customer get with their basic license?
To my knowledge, unless this has changed, customers only get one default language, English. And English cannot be changed out for a different language, even if they will only be using one. For example, if the customer is in Germany and that’s the only location for their business, you cannot switch out German for English unless for some reason this is specifically called out in their contract with SF. If anyone knows something different than this process, please add notes here.
If a customer purchases language packs for BizX, does this automatically mean they have language packs for other modules with their own instances, e.g. JAM and LMS?
Although JAM does have its own instance, it is considered to be part of BizX and all customers have it with their licenses. So yes for JAM. But LMS is different. Because LMS is a completely separate instance, language packs are turned on and configured differently and they have their own pricing. Note that pricing does change so customers should check with their SF Account Exec if there are any questions on whether language packs are included or not.
For BizX modules e.g. EC, PM/GM, Recruiting, once the customer purchases BizX language packs, they are usable for all BizX modules. It just gets tricky when the module is on a different type of instance like LMS.
Is all language work accomplished in admin tools now or must some still be done in XML templates?
Language work is becoming more and more ingrained within the admin tools. Performance, profile, route maps, rating scales, and even Recruiting templates can now be edited in the new admin tools and language translations added there. However, unless I haven’t see something new about Goal Mgmt, you cannot add goal plan translations in admin tools. Keep watching release notes as this will surely change soon.
How can the basic system language be changed other than what you can do in Text Replacement?
The functionality for this is called 3 Tier Architecture which is accomplished in provisioning. A customer can request any system language change. But of course all it takes is time and money by the partner as you cannot do this in admin tools, except for the selections in Text Replacement. There are lots of resources out there to instruct on the configuration and it is not as scary as it sounds. But like everything else, pay careful attention to the details and do it in test first!
Which is the best tool to use with language work, Excel or something else?
For language work, Excel is BAD! Do not use it at all, never, never! Use the free suite of tools called Open Office and the spreadsheet within that tool. You customer will need to learn this as well for competencies, etc.
In provisioning, why are there sometimes duplicates of the same language but one with SF, e.g. es_ES_SF?
This situation should be very rare now and only on a very old instance. But in case you ever see it, do not begin work until the customers instances have been migrated to the new language packs which is an engineering case that your customer will need to open and follow through. Do not begin work until this is completed.
Typically, do partners actually provide translations or does the customer do that on their own?
Of course customers can purchase anything with enough time and money. But normally, the customer provides their own translations. We provide the ‘cookbook’, they add the translations, and then it is normally a combination of work between the customer and partner on who adds the translations. It is most important to let them know right up front about this as I have seen customers be disappointed and not understand they provide the translations.
When during the implementation project is the best time to start the translation process and how much time does this add to a project?
Language translations should be discussed on day one at the kickoff including how it works, the cookbook, who does what, etc. But it is best not to start the actual cookbook and then adding translations until AFTER configuration sign off. You can imagine how many versions of the cookbook would exist if you started earlier than config sign off. If the project timeline accommodates waiting until after config signoff to begin translations, you’ll need to add on about 8 weeks to go live unless they agree to an English only go live first. That being said, the customer work in admin tools should be taught and tested very early on and if they want to add their translations early and go back and correct them, it is up to them.
