You can configure project settings according to your needs in the Settings tab.
For convenient navigation, all project settings are grouped as follows:
- QA Checks
- Translation Memory
- Parsers configuration
In the Name section, you can change the project name and add a public description.
The custom domain lets you publish your Crowdin project on your own domain name.
To set up a custom domain, follow these steps:
- Create a necessary domain in the domain name registrar.
- Create a CNAME record for this domain name that will be pointed to
- Open your Crowdin project and go to Settings > General > Branding.
- Enter the created domain name into the Custom Domain field and click Update.
The project logo allows you to customize the appearance of your project’s main page.
With badges, you can share the localization progress of your Crowdin project by embedding them into your website or README.
To embed badges, follow these steps:
- Open your Crowdin project and go to Settings > General > Badges.
- Enable Display badges.
- Copy the badge code using Markdown, HTML, or Image URL.
- Paste the badge code on your website or README.
This option is accessible exclusively to the project owner. You can delete your Crowdin project with all the translations and related localization resources if necessary.
Note! This action can't be undone.
Privacy & Collaboration
Set the preferred visibility for your project with the following options:
- Public project – public projects can be found via search engines and Crowdin search. Crowdin users can join public projects without approval if the Moderated project joining option is disabled.
- Private project – private projects can’t be found via search engines and Crowdin search. Only the invited users can join the project.
Configure your project privacy settings with the following options:
- Require two-factor authentication for all the project members – request project participants to enable two-factor authentication in their Account Settings > Password & Connections tab to access the private project.
- Moderated project joining – require users to send requests to join the translation team of the preferred language. After the review, a project manager or proofreader can approve or decline the request. After joining the project, multilingual translators can submit new requests to join translation teams in other target languages.
- Allow offline translation – allow translators to download source files to their machines for offline translation and upload translations back into the project. The project owner and managers can always download sources and upload translations, not depending on the option status.
- Allow proofreaders to access hidden strings – allow proofreaders to work with hidden strings. The project owner and managers can always work with hidden strings, not depending on the option status.
- Allow project members to manage glossary terms – allow translators and proofreaders to add new glossary terms to the project. The project owner and managers can always add and edit glossary terms, not depending on the option status.
- Show machine translation suggestions – enable MT suggestions from machine translation engines such as Microsoft Translator, Google Translate, and others to be displayed in the Editor. The project owner should configure machine translation engines before using them.
- Notify translators about new strings – translators will receive an email notification about newly added content for translation each time after the update. The Receive emails option should be activated in the translator’s profile.
- Notify project managers about new strings – project managers will receive an email notification about newly added content for translation each time after the update.
- Notify project managers about language translation/validation completion – project managers will receive the notification when some target language (all source files) is fully translated or fully validated.
In the Languages section, you can manage your project source and target languages and configure language mapping to use custom language codes.
If you want to change the source language for your project, select a new language from the drop-down list and click Update.
Here are a few points you should be aware of when changing the project’s source language:
- Please note that there might be a plural form mismatch for imported strings depending on the new source language. For example, some plural forms might not be displayed in the Editor, or some plural form translations might be used in other ones on translation export. We recommend updating the source files if the new source language has different plural forms than the initial one.
- If you had an opened browser tab with the Editor during the source language update, you might need to refresh it for changes to take effect and continue translating from the new source language.
The Target Languages section allows you to add or remove target languages in your project, copy the target languages list from one project to another, and add custom languages.
Read more about Target Language Management.
Adding Custom Language Codes
To add language mapping, follow these steps:
- Open your project and go to Settings > Languages.
- Scroll down to the Add custom language codes section.
- Click Language Mapping.
- Choose the necessary language and placeholder.
- Add custom code.
- You can map as many languages as you need. Click Add Mapping to add another custom code.
- Click Save.
In the QA Checks section, you can manage the types of QA issues to be highlighted in the Editor during the translation process.
Read more about Quality Assurance Checks.
The project TM is created automatically for each project. Therefore, every approved or the latest added translation is automatically saved to the project TM.
In the Assigned Translation Memories section, you can assign and manage the translation memories for your project.
Read more about Translation Memory.
In the Glossary section, you can enable the translation of the glossary.
In the Assigned Glossaries section, you can assign and manage the glossaries for your project.
Read more about Glossary.
Unify Placeholders – if your project contains iOS strings, iOS XLIFF, and Android XML files, you can enable the Unify placeholders option, and the system will transform placeholders into a unified look. For example, Crowdin will make the Android string
Hello, %s!, and the iOS string
Hello, %@! look in the Editor this way:
Hello, [%s]!. This option is beneficial when you work with TM since TM suggestions from iOS strings, iOS XLIFF, and Android XML will be completely interchangeable. Crowdin will transform the translation placeholders back to the original format on export. This option only applies to iOS strings, iOS XLIFF, and Android XML formats.
Duplicate Strings – if your project contains duplicated strings, you can choose how the system should treat them using the following options:
- Show – translators will translate each instance (string) separately. Duplicated strings won’t be hidden.
- Show, but auto-translate them – Duplicated strings will be automatically translated but will stay visible to translators. Once the string is translated, its translation is automatically shared between the duplicates. Translators may review and re-translate those strings if necessary.
- Show within a version branch (regular detection) – duplicates will be hidden only between version branches.
- Show within a version branch (strict detection) – duplicates will be hidden only between version branches.
- Hide (regular detection) – all duplicates will share the same translation.
- Hide (strict detection) – all duplicates will share the same translation.
Regular duplicate detection – when comparing strings, Crowdin considers only source texts.
Strict duplicate detection – when comparing strings, Crowdin considers both string identifiers (keys) and source texts.
If your source files contain strings with apparent identifiers (keys), it’s better to use a strict version of the Duplicate Strings options. In other cases, feel free to use a regular one.
You can set the preferred way Crowdin should count words in your project. Specifically, it applies to whether HTML tags should be counted as regular words or not. By default, Crowdin considers HTML tags as regular words for most of the supported formats, excluding the following ones: HTML, Front Matter HTML, HAML, MD, Front Matter MD, XML, WEBXML, IDML, XLIFF, XLIFF 2.0, ADOC, DOCX, MIF, DITA.
- Auto (default) – HTML tags will be counted as regular words or skipped depending on the source file format.
- Count tags – all HTML tags will be counted as regular words.
- Skip tags – all HTML tags won’t be counted.
When you change the word count option, only newly uploaded words will be counted according to the new settings. So it’s recommended to set the preferred word count settings before uploading source files to the project.
By default, when exporting translations, Crowdin fills untranslated strings with source text to avoid exporting empty files.
You can configure export options using the following settings:
- Save context information in the files – the context and max.length added in Crowdin will be visible in the downloaded files. This option only applies to CSV, Android XML, iOS strings, and RESX formats.
Note: This option only partially applies to iOS strings and RESX formats (i.e., only the context added in Crowdin will be visible in the downloaded files).
Skip untranslated strings – only translated strings will be included in the exported translation files.
This option works in three different ways, depending on the file format. This option is not applied to text-formatted documents since missing texts can make downloaded files unreadable. Others are exported with empty values. And for the third file category, untranslated strings are entirely removed from the exported translation files.
|Option not applied ||Untranslated strings exported with empty values ||Untranslated strings removed |
|DOCX, IDML, DITA, ADOC, MD, MediaWiki, TXT, HAML, HTML, assets, FM MD, FM HTML, Contentful JSON, SVG ||JSON (with nested structure), PHP, XLSX, CSV, FJS, RC, XAML, XML, Web XML, TypeScript, JS, TOML, QT TS, i18next JSON, gettext PO, FLSNP, Coffee ||Android XML, macOS/iOS Strings, Stringsdict, Chrome JSON, JSON (without nested structure), YAML, XLIFF, XLIFF 2.0, ARB, DTD, RRC, GO JSON, Flex, Joomla INI, Maxthon, Java Properties, Play Properties, Java Properties XML, RES JSON, RESW, RESX, SBV, STR, STF, VTT, WXL, VDF, FBT JSON |
- Skip untranslated files – only translated files will be included in the exported translation archive.
Note: if this option is enabled, it overrides the effect of the Skip untranslated strings option.
- Export only approved translations – only texts that are both translated and approved will be included in the exported translation files.
- Automatically fill in regional dialects – useful when the project is translated into the language dialects (e.g., Spanish, Argentina). On export, translations from Spanish will be automatically copied to untranslated strings in Spanish, Argentina.
By default, Crowdin uses a predefined set of import and export parameters for each supported file format.
With Parsers configuration, you can change some of these settings according to your needs.
Read more about Parsers configuration.