Automated Workflows Series: Apply Any Filters (with AI!✨)

Before you get lost in the various options and filters, read the previous articles in this series to see what you can achieve with Automated Workflows:

• Translate Content Immediately After Uploading with MT
• Fine-Tune Your UX Copy Before Translating It
• Prevent Translation of Unwanted Strings
  

🧰 Why use filters? 🔗

Filters in our Automated Workflows are a powerful way to apply the rules to a subset of keys only.

For example, with an e-commerce app, it is expected to only translate descriptions and longer texts using machine translation and invest extra effort to get product names translated carefully for the target market.

Not all filters are available for all actions, and there are also differences in how filters are used based on the event that triggered the workflow run.

♾️ Applying workflows to all events 🔗

If you keep the Apply to all events checkbox ticked, all of the input keys/translations are processed. However, there are still some internal rules applied as well. For example, the Pretranslate using MT engine action is always run only on the source translations as it doesn't make much sense to use this action in any other way.

❓ How do "include" and "exclude" work? 🔗

Most filters described below allow you to define a list of "include" conditions (or filters) as well as a list of "exclude" conditions.

• If no "include" filters are set, all items will be processed by the workflow action unless they match one of the "exclude" filters.
• If the item matches any of the "include" filters, it will be processed by the workflow action unless it also matches one of the "exclude" filters.
• The "exclude" filter has a higher priority, meaning that if the item is included and excluded simultaneously, it is not processed by the workflow action.

For example, imagine you want to process only keys starting with the prefix a_, so you set up a filter to include only such strings. But some of these strings contain a suffix -z and you do not want these to be processed. By defining both filters, you ensure that only strings that start with the prefix a_ and do not end with the suffix -z will be processed.

➡️ Types of workflow filters 🔗

🚩 Language filters 🔗

With this filter active, the given workflow action is run only if the translations in the selected language/languages initiate the given trigger event.

This filtering is available for all actions except the Pre-translate with MT engine action.

For Copy translations to another language, it only allows you to define a single language, as it wouldn't make sense to copy multiple languages into a single target.

For some actions, such as Hide keys or Show keys, this filtering is only available when the Apply to keys that do not appear in the source language checkbox is ticked.

👥 User filters 🔗

These are available to all trigger events. With this filter active, the given workflow action is run only if the allowed users initiate the given trigger event.

The user depends on the trigger event:

🗣️ Role filters 🔗

This filtering is available for all actions except for Pretranslate with MT engine. However, for some actions, such as Hide keys or Show keys, this filtering only makes sense when the Apply to keys that do not appear in the source language checkbox is ticked.

This filter compares the user role, which is the same user as in User-based filtering, with the selected list. You can choose from a Translator, Trusted Translator, Reviewer, Manager, or Owner.

📌 State filters 🔗

This filtering is available for all actions except for Pretranslate with MT engine. However, for some actions, such as Hide keys or Show keys, this filtering only makes sense when the Apply to keys that do not appear in the source language checkbox is ticked.

The filter compares the current state of the translation to a list of selected choices out of this list:

• The translation must have the current version.
• The translation must not have the current version.
• The translation is waiting for review.
• The translation is not waiting for review.
• The translation has the "source changed" flag set.
• The translation does not have the "source changed" flag set.
• The translation has the "need improvement" flag set.
• The translation does not have the "need improvement" flag set.

State filters allow you to fine-tune the behavior to only apply the workflow to an untranslated key in the given language, etc.

🔖 Tag filters 🔗

Translation tags are currently under development in Localazy, but some internal tags that are automatically assigned or can be used for prioritizing translations are already available. Soon, you will be able to create custom tags and manage them from our UI.

This filtering is available for all actions. The rule is only invoked if the key, translation, or version (depending on what is available based on the trigger event) carries at least one of the included tags and none of the excluded tags.

Most likely, you will want to use filtering with automatically assigned tags, which are:

✏️ Content filters 🔗

It allows you to define a list of inclusive and exclusive rules that compare key, source text, translations, context comments, or file paths to the configured value.

This filtering is available for all actions, but the options may differ. For example, it's not possible to compare translation for Pretranslate with MT engine as it's only triggered for the source language.

Available rules:

Source & translation - plurals and lists

The normal single key is encoded as is. For filters to work easily with more complex values, plurals and string lists are encoded this way:

Plural

ONE: one form
OTHER: other form

List

- item 1
- item 2
- item 3

🦾 AI filters 🔗

AI filters can be configured for the source language and the translation. Again, you can configure it for the translation only if the translation is available (e.g., the language filter is not configured to consider only the source language).

For both the source language and the translation, the analysis is performed, and the filter compares results with your desired values in several categories:

• Conditions - This option allows you to define how to process the filter  - whether it's a list of separate conditions or one complex rule.

1. All conditions below must be valid - All the conditions must be met. This option is useful when creating a complex filter considering several aspects of the analyzed text.
2. Any of the configured conditions must be valid - The filter is considered valid if any of the conditions (except those in the default state) are valid. This option is helpful if you are filtering based on several simple rules (for instance, when you are looking for translations containing profanity, wrong style, or incorrect language).

• Sentiment - Filter texts based on the positive/negative sentiment.
• Gender - Ensure a unified communication style based on your gender preferences.
• Tone - Keep formal/informal style consistent across your whole project.
• Offensive Wording - Detect profanity and harsh words.
• Cultural Issues - Detect possible cultural issues.
• Different Language - Detect that the text is in the correct language.
• Readability Score - Detect texts that are hard to read and understand.

AI filters are great with the Set as Need Improvement action, allowing you to have an additional look at translations that may be, for some reason, unsuitable for your project.

Warning: We instruct Open AI to analyze the text. Open AI provides the resulting values, and depending on the text and its language, they may be inaccurate.

✅ Conclusion 🔗

In summary, Automated Workflows enriched with filters offer a tailored approach to translation management, allowing you to optimize the efficiency and precision of the actions. You can customize actions based on specific criteria such as language, user roles, and tags.

Additionally, integrating AI filters provides advanced analysis capabilities, enabling the detection of sentiment, offensive language, and readability.

Are you ready to start? Set up your Automated Workflows in the Console now.