Translation Management

Projects (Strings)

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:

  1. From the Projects page, click New Project.

    The Add Project window opens.

  2. Provide a name for the project.

  3. From the dropdown lists, select a Main Format and Main Technology from the dropdown lists.

  4. Provide a Point of Contact from the dropdown list.

  5. Click Save.

    The project is added to the profile.

These settings can be changed on the General tab of Project Settings accessed from the More menu.

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:

  1. Hover over a project and click Languages.

    The Languages tab opens.

  2. Click + Add Language. The Add Language window opens.

  3. From the General tab, provide a language name and language code (locale).

  4. From the Advanced tab, select a source language from the dropdown list.

  5. From the Review tab, select review options.

  6. Click Save.

    Language is added to that project.

More languages can be added by clicking Add Language in the Languages tab and can be edited by clicking Phrase_Gear.png.

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).

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:

  1. From a project page, open the Project settings window from the More dropdown list.

  2. Open the Variables tab.

  3. 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.

  4. Click Add variable to add more variables and click the remove_variable.jpg icon to remove them.

  5. 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

  1. Create Strings projects. As per example, project Frontend and project Backend.

  2. Create source locale files corresponding Strings projects.

  3. 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
Was this article helpful?

Sorry about that! In what way was it not helpful?

The article didn’t address my problem.
I couldn’t understand the article.
The feature doesn’t do what I need.
Other reason.

Note that feedback is provided anonymously so we aren't able to reply to questions.
If you'd like to ask a question, submit a request to our Support team.
Thank you for your feedback.