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
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.
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, clickThe
window opens. -
Provide a name for the project.
-
From the dropdown lists, select a
and from the dropdown lists. -
Provide a
from the dropdown list. -
Click Save.
The project is added to the profile.
These settings can be changed on the
tab 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.
The
tab opens. -
Click Add language. The window opens.
-
From the
tab, provide a language name and language code (locale). -
From the
tab, select a source language from the dropdown list. -
From the
tab, select review options. -
Click Save.
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 the
tab of the window.To set a variable, follow these steps:
-
From a project page, open the
window from the dropdown list. -
Open the
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.
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