Multilingual Behavior with PDFs

To better understand the multilingual behavior of system-generated PDF files used for approvals and other system-generated candidate files and requisition files included in system-generated correspondence in the Recruiting Center, we are providing some clarification of what to expect from a language perspective.

If you are using Oracle Taleo Enterprise Edition in only one language, this section does not apply to your implementation and can be skipped.

PDF files are used throughout the Recruiting Center. The following table shows in which files PDFs are available and for which feature.

Feature Requisition File Candidate File Offer File
Requisition Approval Yes
Offer Approval Yes Yes Yes
Interview Request* Yes Yes
ACE Candidate Alert Yes
Share Candidate Yes
* Interview request file behavior is not outlined yet as it is still being researched.

The following table explains the type of data being translated in a PDF file as well as when a translation is available for each type of data.

When is it available? When is it not available?
Container=Field labels and Section headers throughout the file. If translated by a system administrator, or is a system field and has a system provided language.

Note: The candidate file container is always translated into all candidate facing languages. The requisition file container may not always be completely translated into all candidate facing languages because only career section exposed sections need to be translated into all available system languages.

If the field is a custom field that the system administrator has not translated.
Data=Information provided by an end user in the file. If it was provided by an end user in that language.

When the value specified by the end user has an equivalent selection value available in that language.

When the field used is unilingual and presented to the user in the same text regardless of language.

If the end user has not provided a value in that language and the field is a multilingual text field (for example, most compensation fields are multilingual text fields).

The following table indicates in which language the PDF content (container and data) is being translated.

Container Data
Requisition File
  • Requisition Approval

  • Offer Approval

From Tasks: The approver's connected language.

From eShare: The approver's preferred message language, or if a login to eShare is required, the language specified upon entering the eShare Response Center.

Same as container except there is a fallback if data is not translated into the user's language.

Fallback: Requisition base language.

Candidate File
  • ACE Candidate Alert

  • Share Candidate

If the recipient is a Recruiting Center user, the recipient's preferred correspondence language is used; otherwise, the eShare sender's content language is used. Candidate file submission language.
Candidate File
  • Offer Approval

From Tasks: The approver's connected language.

From eShare: The approver's preferred message language, or if a login to eShare is required, the language specified upon entering the eShare Response Center.

Candidate file submission language.
Offer File
  • Offer Approval

From Tasks: The approver's connected language.

From eShare: The approver's preferred message language, or if a login to eShare is required, the language specified upon entering the eShare Response Center.

Same as container. No fallback exists in this case.

File recipients will receive files based on the situations outlined. File content will appear in the language(s) specified. When a language is not available in the language specified, the PDF will render but impacted container/data will be absent.

Here are two examples to illustrate this point as well as guidance on how to resolve it:

Scenario 1: Candidate data presented in PDF to share recipient during share function.

If a candidate applies in Japanese and the share sender's content language preference is English, the share file generated as well as all labels will be in English. Data for the submission file will be unilingual and will render for the user in English for selector fields and Japanese for text fields (this means things like resume text, cover letter text, work experience and education will come through fine). However, any profile based multilingual text and text area fields will not render for the user. This means for example that if the candidate has entered data into a candidate UDFs text field, it will not render to the share recipient if sent by an English content language share sender.

To work past this: If the share sender is sending a Japanese candidate submission and wants the data to be rendered in Japanese to the share recipient, he/she should change his/her content language preference under My Setup to Japanese prior to conducting the share action.

Scenario 2: Requisition approval request not translated into the user's specified content language.

If a requisition is created in English but a user's preferred content language is French, if the requisition has not been translated into French and is routed to that user for approval, fields which are multilingual text will be missing data when it is routed for approval to that user. For example, compensation text fields and job description fields would be impacted by this.

To work past this: Customers should ensure that requisitions are translated into all content languages used by approvers on a specific requisition. If a user does happen to receive a requisition approval request and some data does not come through because it was not translated into the user's content language, the user can log into the system and change his content preference to the appropriate language and then go to generate the requisition file again. This time, it will render in the updated language preference specified that contains all of the data.