Projects (Strings)

Content is machine translated from English by Phrase Language AI.

Projects are where the main components of a translation project (jobs, translation memories, and term bases) are held together. Before files can be assigned for translation as a job, they must be assigned to and contained within a project.

Assigned projects are listed under the Projects tab on the profile page and can be filtered by space.

Depending on team structure, projects can be defined by product or by platform. Use a single project if all team members require access.

Project Page

Opening a project presents it in a project page.

From the project page, all project details can be viewed and edited. All comments, tags, keys and uploads are also presented.

Create a Project

To create a project, follow these steps:

From the Projects page, click New project.

The Add project window opens.
Provide a name for the project.
From the dropdown lists, select a Main format and Main technology from the dropdown lists.
Provide a Point of contact from the dropdown list.
Click Save.

The project is added to the profile.

These settings (i.e. the project name, main format, or point of contact) can be changed on the General tab of Project settings accessed from the More menu.

Existing projects can be duplicated by selecting Duplicate project from the More menu on the Projects page. The duplicated project uses the main file format of the original. If that format does not support pluralization by default, pluralization is unavailable. If no main format is defined, the .CSV format is used by default, with pluralization disabled.

Define a Project

Add Languages

The minimal definition for a project are the source and target languages. These are the original language of texts and the languages it will be translated into and are initially defined in the project setup.

To set up further languages, follow these steps:

Hover over a project and click Languages.

The Languages tab opens.
Click Add language. The Add language window opens.
From the General tab, provide a language name and language code (locale).
From the Advanced tab, select a source language from the dropdown list.
From the Review tab, select review options.
Click Save.

Language is added to that project.

More languages can be added by clicking Add language Add a Language in the Languages tab, and can be edited from the More options Open More Menu menu by selecting Edit Edit language.

Set Variables

Bits of information and flags can be stored in project variables. Variables are set and can be managed via the Translation center and API. Integrations can use project variables to configure workflows of toggle specified behavior.

Variables are typically accessed in scripts via the API. Like environment variables, the value of a project variable is represented as a string, so type must be specified (e.g. boolean, integer).

Example 1

A client has different project types (marketing and product). They set the variable content_type: marketing.
The integration script reads the variable to decide how to proceed with that project (e.g., push it through different QA checks).

Example 2

A client works with Phrase Strings and a CMS. They add the variable template_id: 8734-ABCD .
The integration script reads the variable and fetches the correct template from the CMS when publishing localized content.

Variables can only be set by Administrators and are defined in the Variables tab of the Project settings window.

To set a variable, follow these steps:

From a project page, open the Project settings window from the More dropdown list.
Open the Variables tab.
Provide a name for the variable and a value.

Ideally, names should be similar to environment variables such as MY_VAR and must be unique per project.
Click Add variable to add more variables and click the icon to remove them.
Click Save.

The window closes and variables are saved.

Maintain Multiple Strings Projects for one Localization Project

As software projects grow and become more complex it helps to split them into modules to keep things manageable. Limiting the scope of projects by splitting the translations into smaller categories such as frontend and backend can help with this management.

Example maintenance workflow

Create Strings projects. As per example, project Frontend and project Backend.
Create source locale files corresponding Strings projects.

Create a configuration file that includes the locations of the source locale files in the project and match them to the corresponding Strings projects:

phrase:
  access_token: "3d7e6598d955bfcabaf1b9459df5692ac4c28a17793"
  file_format: yml
  push:
    sources:
    # frontend
    - file: ./path/to/locales/frontend/en.yml
      project_id: "5c05692a2a995c0c45c0c3cbfcab1"
      params:
        locale_id: "159d48e76802f789d9b8fb6d368e61bc"

    # backend
    - file: ./path/to/locales/backend/en.yml
      project_id: "0c45c0c3cbfcab15c05692a2a995c"
      params:
        locale_id: "fb6d368e61bc159d48e76802f789d9b8"
  pull:
    targets:
    # frontend
    - file: ./path/to/locales/frontend/<locale_name>.yml
      project_id: "5c05692a2a995c0c45c0c3cbfcab1"

    # backend
    - file: ./path/to/locales/backend/<locale_name>.yml
      project_id: "0c45c0c3cbfcab15c05692a2a995c"

Providing a config via --config flag

By default, the CLI will try to use a file called .phrase.yml on the same level at which Phrase is run. To support more complex workflows, use multiple configuration files for different purposes.

To force the CLI to use a configuration file for certain commands, supply the corresponding .yml file via the --config flag:

$ phrase push --config ./path/to/config.yml