If only specific pages are translated, the dropdown in the menu bar on any given page will need to correctly link to the corresponding translated page. To do this, follow these steps:

• Click the Page Options tab on the back end of any page that has an equivalent translated version
• Click the “Add New Translation” button
• In the menu that appears, choose “English – en” and the region “United States – us.” Then select the first bullet, “This Domain.” This signifies that the first item in the dropdown will say “English” and will refer to the current page.

• Hit the “Add New Translation” button again to add a translation option. Select the language and the region of the translated page’s content, and then choose the translated page’s name from the dropdown. If the translated page lives on a different site than the current page, then the URL for the translated page may be pasted into the URL field.

• Things to Note:

  • Be sure to set the same page settings on the translated version as well, so that the user can navigate back to the English page the same way they got to the translated page.
  • The FH Site builder should consider adding a custom main nav and footer menu to translated pages which would only show other pages that have been translated. If for some reason the activities are not translated, the menu should still include these for conversion reasons.

If every page on the site has a translated equivalent, navigate to the Settings > Translations Settings. This will function similarly to the Translations on individual pages, but it will create a language dropdown menu in the banner on EVERY page on the site, and will follow the nesting structure that is selected for each language.

There are two possible strategies for translating pages.

1. The Onsite Translations Method: Each individual page is duplicated and translated (and navigable in a subdirectory of the root: [sitename.com/es/pagename/])
2. The Offsite Translations Method: The site itself needs to be duplicated (and the content translated) and sent live on a different website (such as [es.sitename.com/] or [sitename.es/])

The Onsite method

• If the client wants to use a subdirectory for the translated language, the first step is to determine the nesting structure the subdirectory will use, and ensure the translation nesting structure is set correctly in Company Settings > Translations. Then, each translated page must be nested under the translated homepage consistent with the selected nesting structure. For instance, if the Spanish dropdown on the page [sitename.com/tours] will link to [sitename.com/es/tours], it is imperative that the Spanish “tours” page has a slug of [/tours/] and is nested under the Spanish homepage [sitename.com/es/].
  • If a client wants to use translated slugs in the subdirectory, then each individual page would have to have a translation added in page settings, where the translated page is manually selected from a dropdown so that the correct page is found. This is so that if a client translates the page slugs, [sitename.com/about-us/] wouldn’t go to [sitename.com/es/about-us] where it would cause a 404 error, but instead to whatever the translated page’s URL actually is, for instance [sitename.com/es/sobre-nosotros/].

The Offsite method

• If the client wants to use a different site for translations, then the primary language site must be cloned and treated separately.
  • For a Subdomain of the Root Domain
    • In Cloudflare, look at the DNS settings for the primary language site. Create a CNAME for the subdomain (es) that is an alias of the root domain (@). This will ensure that a SSL Cert is issued for the Spanish language subdomain.
  • For any other URL structure (such as [sitename.es/])
    • The site will be taken live as a brand new site, the same as taking any FH site live.
• The nesting structure must exactly match the current site in order to use the global settings (i.e. [sitename.com/tours/10-mile-tour] will need the translated equivalent to live at [es.sitename.com/tours/10-mile-tour]).
• If the client wants to use translated page slugs, add a translation to each individual page of the primary language site. Select the language and region, but since the translated page lives on a different site it will be necessary to copy and paste the translated page’s full URL into the URL field to the right of the dropdown.

Note: To disable the language dropdown on a given page (for instance if there is no translated equivalent of this page), check the box in the Page Options that will disable the translations dropdown from appearing. Do this for all pages where there is no translated version.

Step 1: LSS, Support Agent or AM receives request for translation and posts translation request workflow in #fareharborwebsites.

Step 2: Designated translations approval PC will approve the project or not and comments as such on the workflow thread. * If not approved, LSS, Support Agent or AM will communicate this to the client.

Step 3: If the request is approved, the LSS, Support Agent, AM or whoever submitted the workflow request, will submit the Extended Updates Submission form, selecting “Translation” as the project type. Please be sure to include a link to the Slack thread with approval and the approved languages.

Step 4: The LSS, Support Agent or AM will let the client know that their request was approved and a Project Coordinator will reach out with a translation document once they are ready to start the project. The LSS, Support Agent or AM should also let the client know that in the meantime, the client can start to translate each page on the site into their approved languages.

• If the request came through support, the LSS or support agent will add the Slack link where the request was approved to the ticket as an internal note, and submit as “Solved.”

Step 5: The PC will submit a “Translation Doc Build” task. The WCS will be responsible for putting the translation doc together (adding in the English content or whatever original language content exists on the site that needs to be translated into additional languages). The PC will assist as needed. The translation doc template is here and an example is here.

Step 6: Once complete, the PC will send the translation doc to the client and wait for the client to fill in the translated content.

Step 7: Once the translations have been sent back, the PC will create another task, the actual translation task for the WCS to implement the translations on the site.

Step 8: At this point, the PC will coordinate which sprint is best for the project and change the status to Ready to Rip. The translation project gets assigned to the sprint and assigned to a WCS.

Step 9: The WCS implements translation and changes status to Ready for Review.