Setting up the GitLab Development Kit (GDK)
Tools
Preparing a page for translation
Making changes to translated strings
Working with special content
Best practices
Updating the PO files with the new content
- Validating PO files
Adding a new language
Manually test translations from the UI

Internationalization for GitLab

For working with internationalization (i18n), GNU gettext is used given it’s the most used tool for this task and there are many applications that help us work with it.

All rake commands described on this page must be run on a GitLab instance. This instance is usually the GitLab Development Kit (GDK).

Setting up the GitLab Development Kit (GDK)

To work on the GitLab Community Edition project, you must download and configure it through the GDK.

After you have the GitLab project ready, you can start working on the translation.

Tools

The following tools are used:

Custom written tools to aid day-to-day development work with translations:
- tooling/bin/gettext_extractor locale/gitlab.pot: scan all source files for new content to translate
- rake gettext:compile: reads the contents of the PO files and generates JS files which contain all the available translations for the Frontend.
- rake gettext:lint: validate PO files
gettext_i18n_rails: this gem allows us to translate content from models, views, and controllers. It uses fast_gettext under the hood.

It also provides access to the following Rake tasks, which are rarely needed in day-to-day:
- rake gettext:add_language[language]: adding a new language
- rake gettext:find: parses almost all the files from the Rails application looking for content marked for translation. It then updates the PO files with this content.
- rake gettext:pack: processes the PO files and generates the binary MO files that the application uses.
PO editor: there are multiple applications that can help us work with PO files. A good option is Poedit, which is available for macOS, GNU/Linux, and Windows.

Preparing a page for translation

There are four file types:

Ruby files: models and controllers.
HAML files: view files.
ERB files: used for email templates.
JavaScript files: we mostly work with Vue templates.

Ruby files

If there is a method or variable that works with a raw string, for instance:

def hello
  "Hello world!"
end

Or:

hello = "Hello world!"

You can mark that content for translation with:

def hello
  _("Hello world!")
end

Or:

hello = _("Hello world!")

Be careful when translating strings at the class or module level because these are only evaluated once at class load time. For example:

validates :group_id, uniqueness: { scope: [:project_id], message: _("already shared with this group") }

This is translated when the class loads and results in the error message always being in the default locale. Active Record’s :message option accepts a Proc, so do this instead:

validates :group_id, uniqueness: { scope: [:project_id], message: -> (object, data) { _("already shared with this group") } }

Messages in the API (lib/api/ or app/graphql) do not need to be externalized.

HAML files

Given the following content in HAML:

%h1 Hello world!

You can mark that content for translation with:

%h1= _("Hello world!")

ERB files

Given the following content in ERB:

<h1>Hello world!</h1>

You can mark that content for translation with:

<h1><%= _("Hello world!") %></h1>

JavaScript files

The ~/locale module exports the following key functions for externalization:

__() Mark content for translation (double underscore parenthesis).
s__() Mark namespaced content for translation (s double underscore parenthesis).
n__() Mark pluralized content for translation (n double underscore parenthesis).

import { __, s__, n__ } from '~/locale';

const defaultErrorMessage = s__('Branches|Create branch failed.');
const label = __('Subscribe');
const message =  n__('Apple', 'Apples', 3)

To test JavaScript translations, learn about manually testing translations from the UI.

Vue files

In Vue files, we make the following functions available to Vue templates using the translate mixin:

__()
s__()
n__()
sprintf

This means you can externalize strings in Vue templates without having to import these functions from the ~/locale file:

<template>
  <h1>{{ s__('Branches|Create a new branch') }}</h1>
  <gl-button>{{ __('Create branch') }}</gl-button>
</template>

If you need to translate strings in the Vue component’s JavaScript, you can import the necessary externalization function from the ~/locale file as described in the JavaScript files section.

To test Vue translations, learn about manually testing translations from the UI.

Test files (RSpec)

For RSpec tests, expectations against externalized contents should not be hard coded, because we may need to run the tests with non-default locale, and tests with hard coded contents will fail.

This means any expectations against externalized contents should call the same externalizing method to match the translation.

Bad:

click_button 'Submit review'

expect(rendered).to have_content('Thank you for your feedback!')

Good:

click_button _('Submit review')

expect(rendered).to have_content(_('Thank you for your feedback!'))

Test files (Jest)

For Frontend Jest tests, expectations do not need to reference externalization methods. Externalization is mocked in the Frontend test environment, so the expectations are deterministic across locales (see relevant MR).

Example:

// Bad. Not necessary in Frontend environment.
expect(findText()).toBe(__('Lorem ipsum dolor sit'));
// Good.
expect(findText()).toBe('Lorem ipsum dolor sit');

Recommendations

If strings are reused throughout a component, it can be useful to define these strings as variables. We recommend defining an i18n property on the component’s $options object. If there is a mixture of many-use and single-use strings in the component, consider using this approach to create a local Single Source of Truth for externalized strings.

<script>
  export default {
    i18n: {
      buttonLabel: s__('Plan|Button Label')
    }
  },
</script>

<template>
  <gl-button :aria-label="$options.i18n.buttonLabel">
    {{ $options.i18n.buttonLabel }}
  </gl-button>
</template>

If we are reusing the same translated string in multiple components, it is tempting to add them to a constants.js file instead and import them across our components. However, there are multiple pitfalls to this approach:

It creates distance between the HTML template and the copy, adding an additional level of complexity while navigating our codebase.
The benefit of having a reusable variable is to have one easy place to go to update a value, but for copy it is quite common to have similar strings that aren’t quite the same.

Another practice to avoid when exporting copy strings is to import them in specs. While it might seem like a much more efficient test (if we change the copy, the test will still pass!) it creates additional problems:

There is a risk that the value we import is undefined and we might get a false-positive in our tests (even more so if we import an i18n object, see export constants as primitives).
It is harder to know what we are testing (which copy to expect).
There is a higher risk of typos being missed because we are not re-writing the assertion, but assuming that the value of our constant is the correct one.
The benefit of this approach is minor. Updating the copy in our component and not updating specs is not a big enough benefit to outweigh the potential issues.

As an example:

import { MSG_ALERT_SETTINGS_FORM_ERROR } from 'path/to/constants.js';

// Bad. What is the actual text for `MSG_ALERT_SETTINGS_FORM_ERROR`? If `wrapper.text()` returns undefined, the test may still pass with the wrong values!
expect(wrapper.text()).toBe(MSG_ALERT_SETTINGS_FORM_ERROR);
// Very bad. Same problem as above and we are going through the vm property!
expect(wrapper.text()).toBe(MyComponent.vm.i18n.buttonLabel);
// Good. What we are expecting is very clear and there can be no surprises.
expect(wrapper.text()).toBe('There was an error: Please refresh and hope for the best!');

Dynamic translations

For more details you can see how we keep translations dynamic.

Making changes to translated strings

If you change the source strings in GitLab, you must update the pot file before pushing your changes. If the pot file is out of date, pre-push checks and a pipeline job for gettext fail.

Working with special content

Interpolation

Placeholders in translated text should match the respective source file’s code style. For example use %{created_at} in Ruby but %{createdAt} in JavaScript. Make sure to avoid splitting sentences when adding links.

In Ruby/HAML:

format(_("Hello %{name}"), name: 'Joe') => 'Hello Joe'

In Vue:

Use the GlSprintf component if:

You are including child components in the translation string.
You are including HTML in your translation string.
You are using sprintf and are passing false as the third argument to prevent it from escaping placeholder values.

For example:

<gl-sprintf :message="s__('ClusterIntegration|Learn more about %{linkStart}zones%{linkEnd}')">
  <template #link="{ content }">
    <gl-link :href="somePath">{{ content }}</gl-link>
  </template>
</gl-sprintf>

In other cases, it might be simpler to use sprintf, perhaps in a computed property. For example:

<script>
import { __, sprintf } from '~/locale';

export default {
  ...
  computed: {
    userWelcome() {
      sprintf(__('Hello %{username}'), { username: this.user.name });
    }
  }
  ...
}
</script>

<template>
  <span>{{ userWelcome }}</span>
</template>

In JavaScript (when Vue cannot be used):

import { __, sprintf } from '~/locale';

sprintf(__('Hello %{username}'), { username: 'Joe' }); // => 'Hello Joe'

If you need to use markup within the translation, use sprintf and stop it from escaping placeholder values by passing false as its third argument. You must escape any interpolated dynamic values yourself, for instance using escape from lodash.

import { escape } from 'lodash';
import { __, sprintf } from '~/locale';

let someDynamicValue = '<script>alert("evil")</script>';

// Dangerous:
sprintf(__('This is %{value}'), { value: `<strong>${someDynamicValue}</strong>`, false);
// => 'This is <strong><script>alert('evil')</script></strong>'

// Incorrect:
sprintf(__('This is %{value}'), { value: `<strong>${someDynamicValue}</strong>` });
// => 'This is &lt;strong&gt;&lt;script&gt;alert(&#x27;evil&#x27;)&lt;/script&gt;&lt;/strong&gt;'

// OK:
sprintf(__('This is %{value}'), { value: `<strong>${escape(someDynamicValue)}</strong>` }, false);
// => 'This is <strong>&lt;script&gt;alert(&#x27;evil&#x27;)&lt;/script&gt;</strong>'

Plurals

In Ruby/HAML:

n_('Apple', 'Apples', 3)
# => 'Apples'

Using interpolation:

n_("There is a mouse.", "There are %d mice.", size) % size
# => When size == 1: 'There is a mouse.'
# => When size == 2: 'There are 2 mice.'

Avoid using %d or count variables in singular strings. This allows more natural translation in some languages.

In JavaScript:

n__('Apple', 'Apples', 3)
// => 'Apples'

Using interpolation:

n__('Last day', 'Last %d days', x)
// => When x == 1: 'Last day'
// => When x == 2: 'Last 2 days'

In Vue:

One of the recommended ways to organize translated strings for Vue files is to extract them into a constants.js file. That can be difficult to do when there are pluralized strings because the count variable won’t be known inside the constants file. To overcome this, we recommend creating a function which takes a count argument:

// .../feature/constants.js
import { n__ } from '~/locale';

export const I18N = {
  // Strings that are only singular don't need to be a function
  someDaysRemain: __('Some days remain'),
  daysRemaining(count) { return n__('%d day remaining', '%d days remaining', count); },
};

Then within a Vue component the function can be used to retrieve the correct pluralization form of the string:

// .../feature/components/days_remaining.vue
import { sprintf } from '~/locale';
import { I18N } from '../constants';

<script>
  export default {
    props: {
      days: {
        type: Number,
        required: true,
      },
    },
    i18n: I18N,
  };
</script>

<template>
  <div>
    <span>
      A singular string:
      {{ $options.i18n.someDaysRemain }}
    </span>
    <span>
      A plural string:
      {{ $options.i18n.daysRemaining(days) }}
    </span>
  </div>
</template>

The n_ and n__ methods should only be used to fetch pluralized translations of the same string, not to control the logic of showing different strings for different quantities. For similar strings, pluralize the entire sentence to provide the most context when translating. Some languages have different quantities of target plural forms. For example, Chinese (simplified) has only one target plural form in our translation tool. This means the translator has to choose to translate only one of the strings, and the translation doesn’t behave as intended in the other case.

Below are some examples:

Example 1: For different strings

Use this:

if selected_projects.one?
  selected_projects.first.name
else
  n_("Project selected", "%d projects selected", selected_projects.count)
end

Instead of this:

# incorrect usage example
format(n_("%{project_name}", "%d projects selected", count), project_name: 'GitLab')

Example 2: For similar strings

Use this:

n__('Last day', 'Last %d days', days.length)

Instead of this:

# incorrect usage example
const pluralize = n__('day', 'days', days.length)

if (days.length === 1 ) {
  return sprintf(s__('Last %{pluralize}', pluralize)
}

return sprintf(s__('Last %{dayNumber} %{pluralize}'), { dayNumber: days.length, pluralize })

Namespaces

A namespace is a way to group translations that belong together. They provide context to our translators by adding a prefix followed by the bar symbol (|). For example:

'Namespace|Translated string'

A namespace:

Addresses ambiguity in words. For example: Promotions|Promote vs Epic|Promote.
Allows translators to focus on translating externalized strings that belong to the same product area, rather than arbitrary ones.
Gives a linguistic context to help the translator.

Some languages are more contextual than English. For example, cancel can be translated in different ways depending on how it’s used. To define the context of use, always add a namespace to UI text in English.

Namespaces should be PascalCase.

In Ruby/HAML:
```
s_('OpenedNDaysAgo|Opened')
```
If the translation isn’t found, Opened is returned.
In JavaScript:
```
s__('OpenedNDaysAgo|Opened')
```

The namespace should be removed from the translation. For more details, see the translation guidelines.

HTML

We no longer include HTML directly in the strings that are submitted for translation. This is because:

The translated string can accidentally include invalid HTML.
Translated strings can become an attack vector for XSS, as noted by the Open Web Application Security Project (OWASP).

To include formatting in the translated string, you can do the following:

In Ruby/HAML:

safe_format(_('Some %{strongOpen}bold%{strongClose} text.'), tag_pair(tag.strong, :strongOpen, :strongClose))
# => 'Some <strong>bold</strong> text.'

In JavaScript:

  sprintf(__('Some %{strongOpen}bold%{strongClose} text.'), { strongOpen: '<strong>', strongClose: '</strong>'}, false);

  // => 'Some <strong>bold</strong> text.'

In Vue:

See the section on interpolation.

When this translation helper issue is complete, we plan to update the process of including formatting in translated strings.

Including Angle Brackets

If a string contains angle brackets (</>) that are not used for HTML, the rake gettext:lint linter still flags it. To avoid this error, use the applicable HTML entity code (< or >) instead:

In Ruby/HAML:

safe_format(_('In &lt; 1 hour'))

# => 'In < 1 hour'

In JavaScript:

import { sanitize } from '~/lib/dompurify';

const i18n = { LESS_THAN_ONE_HOUR: sanitize(__('In &lt; 1 hour'), { ALLOWED_TAGS: [] }) };

// ... using the string
element.innerHTML = i18n.LESS_THAN_ONE_HOUR;

// => 'In < 1 hour'

In Vue:

<gl-sprintf :message="s__('In &lt; 1 hours')"/>

// => 'In < 1 hour'

Numbers

Different locales may use different number formats. To support localization of numbers, we use formatNumber, which leverages toLocaleString().

By default, formatNumber formats numbers as strings using the current user locale.

In JavaScript:

import { formatNumber } from '~/locale';

// Assuming "User Preferences > Language" is set to "English":

const tenThousand = formatNumber(10000); // "10,000" (uses comma as decimal symbol in English locale)
const fiftyPercent = formatNumber(0.5, { style: 'percent' }) // "50%" (other options are passed to toLocaleString)

In Vue templates:

<script>
import { formatNumber } from '~/locale';

export default {
  //...
  methods: {
    // ...
    formatNumber,
  },
}
</script>
<template>
<div class="my-number">
  {{ formatNumber(10000) }} <!-- 10,000 -->
</div>
<div class="my-percent">
  {{ formatNumber(0.5,  { style: 'percent' }) }} <!-- 50% -->
</div>
</template>

Dates / times

In JavaScript:

import { createDateTimeFormat } from '~/locale';

const dateFormat = createDateTimeFormat({ year: 'numeric', month: 'long', day: 'numeric' });
console.log(dateFormat.format(new Date('2063-04-05'))) // April 5, 2063

This makes use of Intl.DateTimeFormat.

In Ruby/HAML, there are two ways of adding format to dates and times:
- Using the l helper: for example, l(active_session.created_at, format: :short). We have some predefined formats for dates and times. If you need to add a new format, because other parts of the code could benefit from it, add it to the file en.yml.
- Using strftime: for example, milestone.start_date.strftime('%b %-d'). We use strftime in case none of the formats defined in en.yml match the date/time specifications we need, and if there’s no need to add it as a new format because it’s very particular (for example, it’s only used in a single view).

Best practices

Minimize translation updates

Updates can result in the loss of the translations for this string. To minimize risks, avoid changes to strings unless they:

Add value for the user.
Include extra context for translators.

For example, avoid changes like this:

- _('Number of things: %{count}') % { count: 10 }
+ n_('Number of things: %d', 10)

Keep translations dynamic

There are cases when it makes sense to keep translations together within an array or a hash.

Examples:

Mappings for a dropdown list
Error messages

To store these kinds of data, using a constant seems like the best choice. However, this doesn’t work for translations.

For example, avoid this:

class MyPresenter
  MY_LIST = {
    key_1: _('item 1'),
    key_2: _('item 2'),
    key_3: _('item 3')
  }
end

The translation method (_) is called when the class loads for the first time and translates the text to the default locale. Regardless of the user’s locale, these values are not translated a second time.

A similar thing happens when using class methods with memoization.

For example, avoid this:

class MyModel
  def self.list
    @list ||= {
      key_1: _('item 1'),
      key_2: _('item 2'),
      key_3: _('item 3')
    }
  end
end

This method memoizes the translations using the locale of the user who first called this method.

To avoid these problems, keep the translations dynamic.

Good:

class MyPresenter
  def self.my_list
    {
      key_1: _('item 1'),
      key_2: _('item 2'),
      key_3: _('item 3')
    }.freeze
  end
end

Sometimes there are dynamic translations that the parser can’t find when running bin/rake gettext:find. For these scenarios you can use the N_ method. There’s also an alternative method to translate messages from validation errors.

Splitting sentences

Never split a sentence, as it assumes the sentence’s grammar and structure is the same in all languages.

For example, this:

{{ s__("mrWidget|Set by") }}
{{ author.name }}
{{ s__("mrWidget|to be merged automatically when the pipeline succeeds") }}

Should be externalized as follows:

{{ sprintf(s__("mrWidget|Set by %{author} to be merged automatically when the pipeline succeeds"), { author: author.name }) }}

Avoid splitting sentences when adding links

This also applies when using links in between translated sentences. Otherwise, these texts are not translatable in certain languages.

In Ruby/HAML, instead of:

- zones_link = link_to(s_('ClusterIntegration|zones'), 'https://cloud.google.com/compute/docs/regions-zones/regions-zones', target: '_blank', rel: 'noopener noreferrer')
= s_('ClusterIntegration|Learn more about %{zones_link}').html_safe % { zones_link: zones_link }

Set the link starting and ending HTML fragments as variables:

- zones_link_url = 'https://cloud.google.com/compute/docs/regions-zones/regions-zones'
- zones_link = link_to('', zones_link_url, target: '_blank', rel: 'noopener noreferrer')
= safe_format(s_('ClusterIntegration|Learn more about %{zones_link_start}zones%{zones_link_end}'), tag_pair(zones_link, :zones_link_start, :zones_link_end))

In Vue, instead of:

<template>
  <div>
    <gl-sprintf :message="s__('ClusterIntegration|Learn more about %{link}')">
      <template #link>
        <gl-link
          href="https://cloud.google.com/compute/docs/regions-zones/regions-zones"
          target="_blank"
        >zones</gl-link>
      </template>
    </gl-sprintf>
  </div>
</template>

Set the link starting and ending HTML fragments as placeholders:

<template>
  <div>
    <gl-sprintf :message="s__('ClusterIntegration|Learn more about %{linkStart}zones%{linkEnd}')">
      <template #link="{ content }">
        <gl-link
          href="https://cloud.google.com/compute/docs/regions-zones/regions-zones"
          target="_blank"
        >{{ content }}</gl-link>
      </template>
    </gl-sprintf>
  </div>
</template>

In JavaScript (when Vue cannot be used), instead of:

{{
    sprintf(s__("ClusterIntegration|Learn more about %{link}"), {
        link: '<a href="https://cloud.google.com/compute/docs/regions-zones/regions-zones" target="_blank" rel="noopener noreferrer">zones</a>'
    }, false)
}}

Set the link starting and ending HTML fragments as placeholders:

{{
    sprintf(s__("ClusterIntegration|Learn more about %{linkStart}zones%{linkEnd}"), {
        linkStart: '<a href="https://cloud.google.com/compute/docs/regions-zones/regions-zones" target="_blank" rel="noopener noreferrer">',
        linkEnd: '</a>',
    }, false)
}}

The reasoning behind this is that in some languages words change depending on context. For example, in Japanese は is added to the subject of a sentence and を to the object. This is impossible to translate correctly if you extract individual words from the sentence.

When in doubt, try to follow the best practices described in this Mozilla Developer documentation.

Always pass string literals to the translation helpers

The tooling/bin/gettext_extractor locale/gitlab.pot script parses the codebase and extracts all the strings from the translation helpers ready to be translated.

The script cannot resolve the strings if they are passed as variables or function calls. Therefore, make sure to always pass string literals to the helpers.

// Good
__('Some label');
s__('Namespace', 'Label');
s__('Namespace|Label');
n__('%d apple', '%d apples', appleCount);

// Bad
__(LABEL);
s__(getLabel());
s__(NAMESPACE, LABEL);
n__(LABEL_SINGULAR, LABEL_PLURAL, appleCount);

Updating the PO files with the new content

Now that the new content is marked for translation, run this command to update the locale/gitlab.pot files:

tooling/bin/gettext_extractor locale/gitlab.pot

This command updates the locale/gitlab.pot file with the newly externalized strings and removes any unused strings. Once the changes are on the default branch, Crowdin picks them up and presents them for translation.

You don’t need to check in any changes to the locale/[language]/gitlab.po files. They are updated automatically when translations from Crowdin are merged.

If there are merge conflicts in the gitlab.pot file, you can delete the file and regenerate it using the same command.

Validating PO files

To make sure we keep our translation files up to date, there’s a linter that runs on CI as part of the static-analysis job. To lint the adjustments in PO files locally, you can run rake gettext:lint.

The linter takes the following into account:

Valid PO-file syntax.
Variable usage.
- Only one unnamed (%d) variable, since the order of variables might change in different languages.
- All variables used in the message ID are used in the translation.
- There should be no variables used in a translation that aren’t in the message ID.
Errors during translation.
Presence of angle brackets (< or >).

The errors are grouped per file, and per message ID:

Errors in `locale/zh_HK/gitlab.po`:
  PO-syntax errors
    SimplePoParser::ParserErrorSyntax error in lines
    Syntax error in msgctxt
    Syntax error in msgid
    Syntax error in msgstr
    Syntax error in message_line
    There should be only whitespace until the end of line after the double quote character of a message text.
    Parsing result before error: '{:msgid=>["", "You are going to delete %{project_name_with_namespace}.\\n", "Deleted projects CANNOT be restored!\\n", "Are you ABSOLUTELY sure?"]}'
    SimplePoParser filtered backtrace: SimplePoParser::ParserError
Errors in `locale/zh_TW/gitlab.po`:
  1 pipeline
    <%d 條流水線> is using unknown variables: [%d]
    Failure translating to zh_TW with []: too few arguments

In this output, locale/zh_HK/gitlab.po has syntax errors. The file locale/zh_TW/gitlab.po has variables in the translation that aren’t in the message with ID 1 pipeline.

Adding a new language

A new language should only be added as an option in User Preferences once at least 10% of the strings have been translated and approved. Even though a larger number of strings may have been translated, only the approved translations display in the GitLab UI.

Languages with less than 2% of translations are not available in the UI.

Suppose you want to add translations for a new language, for example, French:

...
AVAILABLE_LANGUAGES = {
  ...,
  'fr' => 'Français'
}.freeze
...

Add the language:
```
bin/rake gettext:add_language[fr]
```
If you want to add a new language for a specific region, the command is similar. You must separate the region with an underscore (_), specify the region in capital letters. For example:
```
bin/rake gettext:add_language[en_GB]
```
Adding the language also creates a new directory at the path locale/fr/. You can now start using your PO editor to edit the PO file located at locale/fr/gitlab.edit.po.
After updating the translations, you must process the PO files to generate the binary MO files, and update the JSON files containing the translations:
```
bin/rake gettext:compile
```
To see the translated content, you must change your preferred language. You can find this under the user’s Settings (/profile).

After checking that the changes are ok, commit the new files. For example:

git add locale/fr/ app/assets/javascripts/locale/fr/
git commit -m "Add French translations for Value Stream Analytics page"

Manually test translations from the UI

To manually test Vue translations:

Change the GitLab localization to another language than English.
Generate JSON files using bin/rake gettext:compile.

Internationalization for GitLab

Setting up the GitLab Development Kit (GDK)

Tools

Preparing a page for translation

Ruby files

HAML files

ERB files

JavaScript files

Vue files

Test files (RSpec)

Test files (Jest)

Recommendations

Dynamic translations

Making changes to translated strings

Working with special content

Interpolation

Plurals

Namespaces

HTML

Including Angle Brackets

Numbers

Dates / times

Best practices

Minimize translation updates

Keep translations dynamic

Splitting sentences

Avoid splitting sentences when adding links

Always pass string literals to the translation helpers

Updating the PO files with the new content

Validating PO files

Adding a new language

Manually test translations from the UI

Help & feedback

Docs

Product

Feature availability and product trials

Get Help