Well, if you translate "Net" to Spanish you get "Red"; and if you translate that again (by mistake), you get "Rojo". There you are :)
"What?!" I asked myself. "To do? Why did they ship me an incomplete file?"
Then I looked to see what the "untranslated" strings were: "ALL" (I don't speak Spanish but have enough of a smattering of European languages that it was immediately obvious what was going on.)
In Sweden we use "OT" as well but it's referring to "Off Topic" and not something Swedish.
A professional translator makes sure to check the context of the translation, it doesn't go blindly translating sentences and words without context.
I took some screenshots because I really liked the interface, but none of them show the bug because I usually stick to en_GB and the problem was spotted in my wife's netbook (she's Spanish teacher and likes to have the OS interface in Spanish to amuse the kids).
When one can't code, it can at least translate ;)
In this context the pronoun "it" would make more sense as "one"; "it" is very rarely used to refer to a person in English.
A professional translator makes sure to check the context of the translation, it doesn't go blindly translating sentences and words without context.
Again, in this context, "it doesn't" might make more sense as "he or she doesn't", or less formally, "they don't".
Hope this helps with your translations :-)
This coming from someone doesn't speak English as their first language.
I speak Romanian, Hungarian and English perfectly but my devices are always in English since it would be harder to figure out what they mean otherwise unless you have the structure memorized already.
One problem is that English is the language majority of technology is created in, and it has developed agreed-on terms for a lot of things. Everyone calls their tabs "tabs" in English, but when it comes to translating, every other app uses a different word. Even if names are consistent within the app, they are inconsistent between each other. This leads to a lot of problems if say, an app reports an error that's related to some OS thing, and calls it with a different translated name than the OS translation does.
EDIT: And I'm not making this up. I worked on a localized Ubuntu for a very short while before switching back to English because messages I got in my command line were painfully inconsistent with each other and with agreed-upon proper translations in my language.
In all seriousness, translators make mistakes by getting the context wrong all the time; this applies to both professional translators and amateurs, perhaps in different severity. But in my eyes that's not really a problem of the translators, but rather of the tools we use. A long list of strings that have maybe only a vague context is a horribly UX for the translator. Who would fault them to translate »outline« as »Gliederung« in a word processing application? A string table is probably the most convenient format for programmers, but not very much so for those maintaining translations.
Qt gets a bit of this right. If the translator has access to the source code and uses Qt Linguist, at least the strings that are directly in .ui files are shown with a mock-up of the respective window where the control with that text is highlighted [0]. That already helps a lot with context errors. Of course, it does nothing for text in the source code, and so our translator went ahead and translated »Breite« (line width) with »latitude« because the application in question was, after all, related to maps, geography and GPS; it just happened to have a setting to change the width of certain lines, which, in German, then mapped to the same word.
Qt also has a nice way of handling plurals in that both Linguist and the QTranslator class are aware of the languages and the special rules concerning plural forms in them. You create a translatable string like »Searched %n directories« and then create translations for that. English, German and lots of others just map to two forms (1, rest). Russian gets three, I think (1/21/31/..., 2/22/32/..., 11/12/rest), and so on. Downside is that you only get to handle a single plural in a string [1], and you have to create an en→en translation as well (to account for multiple forms in the source language). But generally it's a quite nice implementation. Gettext has something similar where you can write your own plural form matching rules somehow, but most translators I met don't really want to write math.
Visual Studio with Windows Forms has a mode of creating the string tables for translation where you can just change the language in the Form's properties and then proceed to change each control text. This nicely solves the context problem in that the translator edits the window directly and it looks like it normally does. But it also creates a whole bunch of other problems: Translators need VS, they need to edit the project directly and can accidentally mess up the UI with a mouse twitch when selecting a button to translate. They also might miss things that are buried in menus since there is no real measurement of completion and what's still missing. I've seen various projects, especially in web environments adopt a similar custom-written approach, though, where you can edit the UI directly in the application to translate it. Still with the problem that translators might miss hard-to-find and buried strings (one might argue that you should get rid of buried and obscure places in your UI anyway, though).
Long ramblings ... it was a topic I considered for my Diploma thesis while studying. But I couldn't think of a good way that could retain context for the translator in a general case, or at least most of the time. I thought about replacing each and every translatable string in a program with a custom identifier and then later trying to find those again via UI Automation or maybe screenshots and OCR to be able to map strings to parts of screenshots of the program. Would have required running the program once with those custom identifiers and once in normal mode and somehow matching up identifiered screenshots, normal screenshots and the string tables. And still with the problem that you'd need to manually go down each and every dialog and menu, including context menus, messages that only appear in certain states, etc.
Perhaps there just is no good solution, except maybe for developers to properly annotate each translatable string they use. In the »Breite«/»width«/»latitude« case I went through the source and added translator comments detailing the meaning of the word for every instance, but with large applications having thousands of translatable strings that could become unwieldy quickly.
__________
[0] http://geoinformatics.fsv.cvut.cz/wiki/images/thumb/3/39/Qt_...
I like the Visual Studio approach. I usually resort to running the software I'm translating to get context. Sometimes it's very hard to get some of the text to show up.
I can only think of one way to give translators context: Comments, the exact same way you give other programmers context for your code.
How about assigning identifiers to all strings, then adding tooltips for those identifiers in the application? So the translator can hover over a menu item to determine which string they are supposed to translate.
This requires the translator to exercise the whole application which is kind of difficult, as well, of course.
But yes, the requirement to cover every control, menu and dialog as well as every possible code path that uses a localisable string from the source code makes the whole endeavour very impractical to solve. With dialogs built in markup, e.g. Qt's .ui or XAML it's easy enough to give context, but the hard part is strings in code where you never know where they'll end up.
In a particularly expensive piece of enterprise software for the finance sector that was translated into German a form field was labelled 'Hauptstadt', which translates back into 'capital (city)' as in Washington, D.C.
Now, this kind of geographic information doesn't make sense at all in financial software but the well-paid developer (who had to double as the software's translator because hiring a proper translator would of course have been too expensive ...) simply couldn't be bothered to look up the different words 'capital' translates to in German, one of which also is the right choice in that case: 'Kapital' (meaning 'capital' as in 'asset).
Or maybe he did and his boss told him to shut up and do as he's told. Or he thought - "Screw this, I wanna go home on time. I'm not gonna bother to find an Arabic translator now. I'll just paint exactly what it says, and they can't get me in much trouble for that."
From my experience with both software and movies, that's exactly what a professional, paid translator does (or is forced to).
Amateurs at least watch the movie/run the software before translating things, which is something I definitely cannot say about "professionals" translating movies and software to my language.
Not to mention the difficulty in getting them to use Virtaal or PoEdit properly.
A little of anecdata: In Portugal, where foreign stuff is translated and subtitled, the quality of translations/subtitles in english language movies and series in very good. Or at least it used to be, I can't be sure anymore since I don't currently watch TV. I grew up used to reading good translations. Those translations taught me to understand and speak the English language when I was growing up, since age 5. I understand I might be a bit biased because of my personal experience.
1. professional translators are human and make mistakes
2. context may not be available for third-party translators working on e.g. unreleased software strings (see currently top comment by "eloisant")
Not everyone here speaks English as a first language and translating a non-gendered/unknown pronoun to English may result in "it".