Reper Ops

Guides

Fault and Maintenance Records on a Multilingual Site: Everyone Writes in Their Own Language

On a site where the crew works in different languages, fault and maintenance notes are stored in the original, shown to each reader in their own language, and managed with a quota and consistent terms.

Published:6 min read
Fault list on a phone, with one record's title in the user's language and an automatically translated note below it

Short answer: the writer writes in their own language, the reader reads in theirs

On projects abroad or in mixed crews, the technician may work in Arabic, the foreman in Turkish and the head office in English. If everyone has to write fault notes in one language, notes come out wrong or incomplete. The better way is to let the writer use their own language and show the note to the reader in theirs. The original text is never replaced by the translation. The translation is kept next to it as a separate record.

This is not magic. It is an aid that has to be used with care. The sections below separate when translation helps, which notes it never touches, and when you should go back to the original text.

The journey of one fault note

The process has five steps and asks nothing extra from the writer when a fault is opened in the fault management module.

  • The technician opens the fault record in their own language: title, description and, if needed, a part note.
  • The record is stored with its original text, and a translation job is queued in the background. Until the translation is ready, the reader sees the original.
  • The interface languages chosen by the active users on the project become the target languages (Kyrgyz is not a target). The language of the written text is removed from the targets.
  • The foreman reads the record in their own language, with the note Automatically translated (from … ) shown on the record.
  • If they need to check the original, one tap on Show original does it, and Show translation takes them back.

Three separate ideas: interface language, text language, translation support

On a multilingual site three ideas are often mixed up. The interface language is the one a user chooses on their Profile page, in which menus and buttons appear. In the web application these are Turkish, English, Russian, Arabic, French, Romanian and Kyrgyz. In the mobile application the language is chosen separately and saved to the server, and Russian is not available on mobile. In Arabic the screen runs right to left. The text language is the language the note was actually written in, and it can differ from the interface language: a user with a Turkish interface can write a note in Arabic. Translation support is the set of languages the system can translate automatically. A language being selectable in the interface does not mean translation is done in that language.

The system recognises the language of a note from the writing itself. Arabic script is treated as Arabic. Cyrillic text is treated as Russian, but if letters specific to Kyrgyz (ң, ө, ү) are seen, the text counts as Kyrgyz and is not translated. In Latin-script text of enough length, the language is detected automatically. The writer's interface language is only a hint for very short notes. The text itself is the real measure. The limits are:

  • In short Latin-script notes the hint can mislead. If a user with a Turkish interface writes an English note of fewer than about twenty letters, the text may be taken as Turkish and the translation will make no sense. Write short notes in the language of your interface, or add a few more words.
  • Kyrgyz notes are not translated automatically. They appear in the original. Nothing is translated into Kyrgyz either: a user with a Kyrgyz interface sees notes written in other languages untranslated, in the language they were written.
  • A short Cyrillic note with no Kyrgyz letters does not show which language the writer used. If a user with a Russian interface writes a short Kyrgyz note, it may be taken as Russian and translated wrongly. If a user with a Kyrgyz interface writes a Cyrillic note of fewer than about 60 letters, the text is left untranslated because of the uncertainty.

Example flow: from the night shift to the morning meeting

Example: on the night shift, a technician writes about a leak from an excavator's hydraulic hose in his own language and opens the record. In the title he puts the machine code, and in the description the place of the leak and that the machine cannot be operated. When the translation is ready, the foreman on the morning shift reads the same record on his phone in English. He sees a note saying it was translated from Arabic. He does not understand where the hose is, so he taps Show original and talks to the technician.

The translation does two jobs here. It makes the record readable for everyone, and it sends the foreman to ask the technician. A translation is not a work order. The technical knowledge still passes between people.

How to write a good fault note

The quality of the translation depends on the quality of the source text. A short, orderly note is easier to translate and easier to read. The order below is an example. Each company can set up its own template.

  • Title: machine code, part and symptom. Example: EXC-04 left hydraulic hose, oil leak.
  • Description: when it was noticed, under what conditions it got worse, what was tried. Three or four short sentences are enough.
  • Can the machine operate: tick the matching option in the record form. Do not bury it in the text.
  • Part note: the name of the part needed and its reference number if there is one. Writing the code and the quantity apart from the words reduces the risk of misreading.

What is translated and what is not

Only free-text fields that are shown on screen are translated. This limit makes both the quota and the expectations clear.

  • Translated: the fault title, description, part note, resolution note and comments; the title, description and rejection reason of a maintenance work order; the title, reason and free-text lines of a material request.
  • Not translated: plate numbers, machine codes and meter values, and definition records such as category names. A category name is a single-language field set by the company.
  • Not translated: very short notes (a single word, or fewer than about eight letters) and notes made up only of a code or an abbreviation, such as a field that says only ARZ-204 or HYD. These appear as written.
  • Not translated: notes written in Kyrgyz, and any single field of more than five thousand characters.
  • If a translation cannot be produced, for example when the service cannot be reached or the monthly limit is used up, the reader sees the original text.
  • The labels for priority and status come in the interface language and need no translation.
  • In the mobile application the translation is shown on the fault detail screen. There is no translation on the maintenance work order detail screen for now.
  • Excel and PDF reports print the original text. No translation appears in official output.

Quota and settings: what the administrator does

Automatic content translation is not a feature that comes with every package. It is switched on in the company settings, it is off by default, and whether it is available depends on the package quoted. Confirm with the sales team whether it is in your package. The administrator sets the status to On on the Automatic content translation card on the Settings page and chooses the Monthly character limit. The default limit is 20,000 characters, and the card shows how many characters are used this month against the limit. The limit can be set between 1,000 and 2,000,000.

Example calculation: a fault note of 300 characters uses about 600 characters if the project has two target languages besides the language of the text. On that assumption, 20,000 characters cover about 33 fault records. As the number of target languages grows, the use multiplies. Keeping notes short and knowing how many languages the project has protects the quota. Short notes and code notes that are not translated do not use any quota. When the limit is reached, new notes are not translated and appear in the original.

Consistent terms: practice instead of a glossary

This feature does not keep a company-specific glossary. Consistency of terms comes from writing habits. A sentence written with a local idiom on site can be translated wrongly.

Three rules help: write one job in each sentence, give the part name and the machine code side by side, and use a plain verb instead of a local idiom. For example, a note saying the machine will not go can be read as will not run or will not travel. A note saying the machine does not move, the engine is running has one meaning. Handing out a shared list of the ten terms the crew uses most raises the quality of records, whether or not a translation is used.

A set-up check for the administrator

Make six short checks before you switch the feature on. Each one removes a wrong expectation in advance. If you have not yet tried fault recording on your own machines, the 15-day pilot plan shows how to do it.

  • Have the users working on the project chosen their interface languages in their profiles? A language that is not chosen does not become a target.
  • Are there Kyrgyz speakers in the crew? Their notes are not translated, and nothing is translated for them. The crew needs a habit of short notes in a shared language.
  • Has the monthly character limit been set to a sensible number, multiplied by the number of languages on the project?
  • Has a test record been opened, and have the translation and the Show original button been tried in two different languages?
  • Are category names and definition lists written in the crew's shared language? They are not translated.
  • Has the crew been told that the original text appears in official output, that is, in Excel and PDF reports?

Check the original on safety notes

For safety-related notes, for example a fault on a pressurised hose, lifting equipment or brakes, do not rely on the translation alone. The reader should press Show original or speak to the person who wrote it, and confirm. Reper Axis makes reading easier. It does not make the decision, and it does not take the place of the writer.

Frequently asked questions

Does the person who opens the fault record see the translation?

They wrote it in their own language, so they see the original text. A person reading in another language sees the translation, with the Automatically translated note.

Can a wrong translation be corrected?

A translation is not edited by hand. If the writer corrects the note, the translation is produced again. To return to the original text, choose Show original.

What happens when a user who works in a new language is added?

The user only has to choose their interface language. If a user on the project has chosen that language, it becomes a target. No translation is produced for a user who chooses Kyrgyz, and texts appear as they were written.

Is there translation for a crew that writes in Kyrgyz or uses the Kyrgyz interface?

No. The Kyrgyz interface can be selected, but there is no translation support. Kyrgyz notes appear in the original without translation, and no note is translated into Kyrgyz. If the crew includes Kyrgyz speakers, short notes in a shared language or a face-to-face handover are needed.

Why was a short note not translated?

Notes of a single word or fewer than about eight letters, and notes that contain only a code or an abbreviation, are not translated. Writing the note in at least two words and in plain terms makes translation possible.

Reper Axis

A 15-day pilot with your own fleet

The pilot is free and runs with up to 10 machines. Send us your machine list and we load it into the system. Fault, maintenance and timesheet are on; the timesheet is a separately priced module in the annual licence. You work in an account set up for your company. Nothing is charged automatically.

Request a pilot
Contact formWhatsApp