We're considering a change to Mattermost translations ... and we want to hear from you!

Hi! :wave: We’re evaluating whether it makes sense to continue translating all of our Mattermost server-side components, such as logs, database error messages, API errors, and email templates, into all of our supported languages. And we need your input!

Translating server-side components is a great idea, in theory. All text in a product should be presented to a user in the user’s local language. It’s a best practice approach for companies with global reach. From a user’s perspective, trying to troubleshoot an error message in a language you don’t understand is irritating to say the least!

However, we’re translating some server-side strings that aren’t visible to end users, and we’re wondering whether that’s the best use of a translator’s time and effort. The technical nature of logs and database error messages, which are designed for and consumed by developers and debugger tools, makes those strings challenging to translate into languages beyond English.

If we stopped providing translations for server-side components that aren’t visible to end users, these components would display in English. System Admins will likely find more relevant troubleshooting information or workarounds by searching for the string online in English, rather than searching the translated string. System Admins would also continue to share such data with Mattermost Support in English, as the vast majority of our customers do today. (It’s rare that we receive translated logs or errors in the context of a customer support ticket.)

We want your input on this important decision! As a Mattermost community member, product user, system admin, customer, advocate, developer, integrator, or tool evaluator – if Mattermost stopped translating server-side components that aren’t visible to users, what impact would this have for you? Would this impact you negatively, and if so, how?

Share your thoughts with us here in this forum thread, or join us in the i18n - Localization Community channel to say hello and tell us what you think.

1 Like

I vote for keeping them in English only. The argument of consistency of internal error messages and finding a bigger set of pages when searching for the error, along with the fact that the vast majority of people that are going to read these messages are already comfortable with technical English just makes sense to me.

2 Likes

I vote for English too. Even while Dutch is my native language it’s much easier to communicate in technical English concerning system administration. Even with Dutch colleagues…! Using translated technical English only confuses me.

I don’t think I ever came across a translated admin level string in Mattermost, possibly because my OSs are set to english as well? In any case, please keep everything admin level in English. There are better places to spend a translators/engineers time.

That’s exactly how I see it.

Thank you all for your feedback and input on this decision. Together, we unanimously agree that it’s time to stop translating server-side components that aren’t visible to users. :tada: :muscle:t2:

Here’s what’s going to happen next:

  • I’m working with Engineering to identify which server strings are user-facing and which can safely be removed from translation workflows via Weblate. We’re tracking this investigation work via MM-40109.
  • When the investigation work is complete, I’ll provide a detailed update of the strings affected in our Mattermost Community i18n - Localization channel, and a timeline of when of this translation scope decrease will be completed.
  • The i18n channel is a great place to ask any questions or share any concerns you have about this reduction in translation scope.

Thanks again for weighing in and sharing your thoughts!

1 Like