Credit Conditions - Client Acceptance

Translations

The email with the approved credit conditions sent to the Client should be translated in the language (supported by Ebury) selected by Sales/Dealing/Solutions (S/D/S) at the time of sending. Also, both the email and the confirmation page should display branding elements (typically, logo and background) that belong to the respective company that is sending the Credit Conditions, this could be Ebury or could be a Partner.

Problem Description

At the moment, the credit conditions are being sent from BOS by Risk & Treasury (R&T), after the credit conditions have been approved in Salesforce (SF) and manually imported in BOS. BOS has a mechanism to construct the email, translate it in the corresponding language and associate the corresponding branding, before sending. Since we are moving the process to SF and sending the email before the credit conditions are automatically synced to BOS, the operation of sending the email from BOS will become obsolete.

The main issue is that SF currently does not have any process or functionality in place for translations or for dealing with branding.

Background

This implementation is part of the Credit Condition 2.0 Project, currently in phase 4; previous phases are depicted in the diagram. The details of that solution can be found on the previous RFC: Credit Conditions - Client Acceptance.

Solution

Ebury does not have, at the moment, a dedicated function that looks after the content or is responsible for translations. The translations are performed in a collaborative way by many members of the team(s), using a localization management tool - Crowdin. SF has a native feature for translations, albeit with a few limitations. It makes sense to leverage these two functionalities for this purpose.

How will this work?

Crowdin
  1. Ebury already has licensing from Crowdin the SF team has been provided with a project (Ebury-sf) where we will be managing our translations.
  2. The Ebury-sf project will be linked to a Bitbucket repository (sfdx-translations) where we will store the translation source files. This is a separate repo from our main sfdx repo.
  3. The source and translated files should be in format XLIFF - XML Localization Interchange File Format (.xlf) - this is an xml-based format created to standardize the way localizable data is passed between and understood by different tools. This format is supported by SF.
  4. The translation in itself is performed by anyone assigned to the project. Typically when new translations are required, an email needs to be sent to translationteam@ebury.com and the members notified will do the translations. Note: The translations are subjected to the availability of the members of this team; as this is not their main line of work, requests should be sent with some time in advance and projects should take into consideration the time it might take for the translations to be complete.
SF
  1. At the moment, SF Translations is not a functionality that is being used by Ebury, so this will need to be enabled in all orgs. After enabling, this will be used, at least for the time being, in only a subset of the platform - for the credit condition emails.

  2. The email templates will be constructed compiling a set of custom labels, which consist in paragraphs or individual parts of the email that can be translated into a specific language. Note: The labels have been sorted by order of appearance in the emails and categorized here. The custom labels are created in the following format:

    • CC_Email_ - indicates where this label is used;
    • first few words of the paragraph - indicates which text of the email it corresponds to.

    Example:

    ```
fullName: CC_Email_We_Are_Pleased
shortDescription: CC_Email_We_Are_Pleased
categories: credit-request;credit-email
language: en_US
value: We are pleased to grant to {0} a credit line subject to the following credit conditions.
```

  3. The custom labels can be exported in .xlf format using the SF Translation Workbench. Because this is an xml file, the source file can also be easily updated, every time there is a need to add a new component, without the need to export the file again.

  4. Once the translation is done and the translated files, in their respective languages are exported from Crowdin, they can be imported in SF, also using the workbench.
  5. The metadata of the translation is retrieved from the org and added to the deployment packages, so it can be tracked in our main sfdx repository.

This process is new and not very refined, it also requires a number of manual steps, but it is simple enough to allow us to start. With time, we should be able to understand the flow better, its pain-points and its effectiveness and make changes to improve it.

Alternatives

BOS

One alternative would be for SF to leverage the existing functionality that BOS already has to send the email with the Credit Conditions to the Client and therefore, leverage the same mechanism to translate and “brand” the emails. The main issues with this approach are:

  • it would require work to be done on the BOS side, to expose these functionalities in an api, so they can be used by SF; at present, the team is out of capacity and the project would be delayed considerably;
  • there is no mechanism for the client to accept/reject the credit conditions, it is all done manually and the acceptance is not recorded in any system, aside from email. To have this, BOS would either have to build it or build a way to redirect to the confirmation page SF Communities.

Caveats

  • As stated previously, the process requires a lot of manual steps, but we expect that this kind of work will not be frequent, therefore it can be manageable on a project basis. If it does become more frequent in the future, we should think about ways to make the process simpler and smoother.
  • There is no clearly defined structure of who should be responsible for the translations, as in a dedicated team that looks after all content, including translations. As we are dealing with “legal” language, perhaps the translations would require a more strict approach.
  • Ebury’s Crowdin plan currently has a limitation on the number of strings that can be uploaded in the platform and since there are other projects from other teams in the platform, this number can be reached fairly quickly. For this reason, the source file exported from SF, which contains all translatable strings in the org, needs to be stripped of all strings that are not relevant, in this case the source file only contains the custom labels used in the emails and in the confirmation landing page.
  • Unfortunately, the languages supported by Ebury don’t match 100% the languages supported by SF; in this case, we need to be a bit flexible and only account for the ones supported by SF. The mapping of supported languages can be found here.

Operation

The process will be managed on the SF side; most of the work requires managing repos, dealing with metadata, deployments, etc. The translation will be performed by selected individuals that are knowledgeable of the languages to translate to.

Security Impact

N/A

Performance Impact

N/A

Developer Impact

N/A

Data Consumer Impact

N/A

Deployment

Translations are part of the SF metadata, meaning all changes can be tracked on our repos and deployed to the orgs using our current deployment process.

Dependencies

Main dependency is the availability of the people doing the translations in Crowdin.

References