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 thetab 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.
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.
To create a project, follow these steps:
From the New project.page, click
Provide a name for the project.
From the dropdown lists, select aand from the dropdown lists.
Provide afrom the dropdown list.
The project is added to the profile.
These settings can be changed on thetab of accessed from the menu.
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.
Click Add language. The window opens.
From thetab, provide a language name and language code (locale).
From thetab, select a source language from the dropdown list.
From thetab, select review options.
Language is added to that project.
More languages can be added by clicking Add language in the tab and can be edited from the More menu and selecting .
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 thetab of the window.
To set a variable, follow these steps:
From a project page, open thewindow from the dropdown list.
Provide a name for the variable and a value.
Ideally, names should be similar to environment variables such as
MY_VARand must be unique per project.
Click Add variable to add more variables and click the icon to remove them.
The window closes and variables are saved.
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
$ phrase push --config ./path/to/config.yml