Slovenian vs. Slovene

Is the name of the language Slovenian or Slovene?

We usually get this question from our clients: Is the name of the language Slovenian or Slovene? What’s the difference between the two terms?
Slovene:
Noun – Slovenec (person), Slovenka (person), slovenščina (language)
Adjective – slovenski (language)
Slovenian:
Noun – slovenščina (language)
Adjective – slovenski (language)

It seems that there is long history regarding the two terms. Slovene and Slovenian as both nouns and adjectives referring to Slovenia and its people.

Apparently the terms are equally as old; they originate from the 19th century (Slovenian first appeared in an English dictionary in 1844, and Slovene in 1883). In modern English both terms coexist, some people prefer to use Slovenian while others prefer to use Slovene. There has been a lot of debate over this matter, but the bottom line is that both terms can be used as they are equally "correct" and acceptable as long as you use the term consistently. Maybe there is a trend towards Slovenian (the official EU web site for example has a ratio of 1:6 in favor of Slovenian), but you can also find people who disagree (the British National Corpus or the New York Times seem to like Slovene, BBC has a subdivision called BBC Slovene etc.). Also a Goggle search of “Slovenian language” versus “Slovene language” resulted 3 to 1 in favor of “Slovenian.”

So…Which term shall we use?

ISO lists the language as “Slovenian”. As we are an ISO-certified company, as many of our clients are, we suggest using the same terminology as ISO.

Role of the Engineer in the Localization Industry

Software engineering, and more specifically localization engineering takes a certain kind of individual. It most certainly isn’t for everyone. Most people who get into the field develop an aversion to the machines after a short period of time and only use them on the clock or when asked. Their hearts may have been in the right place, but when facing the tedious, more arduous side of engineering, they’d rather be anywhere else than in front of the monitor.

The role of the engineer in the localization industry is multifaceted. Most people not in tune with the translation and localization industry may not realize this team member’s importance or even if an engineer is necessary. After all we are translating words and text. However, when you take into consideration the multiple applications in which the text can be written and the different software platforms that they can be built upon, then it’s obvious that an engineer with experience in software is necessary.

Amongst troubleshooting needs that may arise when working in different software environments, there are specific areas where an engineer lends his expertise to the localization team. Up front, prior to the project starting, the project manager and the linguist count on the engineer do perform a complete analysis of the software documentation that will be translated. This includes running the text through a software tool which compares it to existing translation memory and recognizes any repetitious segments. This leverage is used by the linguist for consistency and by the account manager for cost reduction. Also included in this analysis are specifics regarding the layout and format of the document(s). Considerations must be made if there is text within any images or graphics as part of the documentation as well as overall layout concerns, such as fonts or directionality of text, for different target languages and text.

During a project, the project manager will look to the engineer to complete the desktop publishing work, if necessary, and/or handle any web specific needs and platforms if the project calls for this. Again, handling different software language such as xml, html, RoboHelp, and others all fall under the job requirements of the localization engineer. A verifiable Jack of all Trades with the requirement of mastering each and every engineering need.

XML in the Localization industry

Extensible Markup Language (XML) is a platform-independent way to represent data. Simply put, XML enables you to create data that can be read by any application on any platform. You can even edit and create it by hand because it is based on the same tag-based technology that underlies HTML. That is why XML is considered an extensible language. Because of the freedom of the tags, however, the way in which XML must be written is very strict. Every tag must have a closing tag and all nodes must be ordered properly. If any of these rules are broken, an XML document will simply fail to function. HTML, as many have found, will work even if the document only vaguely looks like an HTML document.

XML is concerned with the electronic representation of the structure and content of information. It is a simplified subset of an ISO standard known as SGML (Standard Generalized Markup Language). Extensible Markup Language is the key to creating markups that can be used by any number of applications beyond the Web browser. In other words, XML is independent of the application that created it.

Some publishers that can import and/or export text in XML format are:

• Indesign

• QuarkXpress

• FrameMaker

• PageMaker

With XML it becomes feasible to target multiple output formats from a single XML source document.

Maybe it is a little hard to understand, but XML does not DO anything. XML was created to structure, store, and transport information. An example of an XML element is as illustrated:

XML in the Localization industry

João

Lima

The DTD is the part of an XML document that declares exactly what tags your document will have and how they will be arranged in the document. The XML document itself must then conform to the rules set by the corresponding DTD. The DTD can either be part of the XML document or it can be referenced by the XML document and really be stored in a separate file, possibly even on a different server. Using XML facilities we can:

• Customize style sheets from client’s XML DTD

• Convert from one XML DTD to another

XLIFF, which stands for XML Localization Interchange File Format, enables translators to concentrate on the text to be translated. Likewise, since it's a standard, manipulating XLIFF files makes localization engineering easier: once you have converters written for your source file formats, you can simply write new tools to deal with XLIFF and not worry about the original file format. It also supports a full localization process by providing tags and attributes for review comments, the translation status of individual strings, and metrics such as word counts of the source sentences.

One of the main problems in localizing files is the complexity of the various file formats. When a file is converted to XLIFF, the structural formatting is extracted and stored in a skeleton file. XLIFF allows many separate tools to work on files. While working on source file formats, it is not easy to have multiple tools work on the same files.

In summary, XLIFF aids localization in a number of ways.

• XLIFF removes the complexities of localizing different types of source files.

• XLIFF provides a common platform for localization tools vendors to write to, thus increasing the number of tools available.

• XLIFF highlights the parts of a file that are important to the localization process.

• XLIFF provides support to the localization process, through its commenting features, support for phases, and metrics.

Cross-Media Publishing

Cross-media publishing is certainly one of the hottest catch phrases in the graphic communications industry. Although most people will admit that print is not exactly dead, there is little doubt that digital media at the very least have become legitimate communicating channels for companies to broadcast their message.

Regardless of which media are being used, the message must still be presented clearly and attractively, in other words: design still needs to support the message. The internet is a very different medium than print from a design perspective.

Web design has its own set of rules, which are sometimes very different than the ones followed for print design. Here are some examples:

• Color management: this is non-existent because you simply can’t calibrate the monitor of every web user.
• Font management: fonts can be controlled to some extent, but without converting all type to graphics — potentially making your site inaccessible to anyone with a slow connection — your pages might be displayed in whatever font the user defines instead of the one you so carefully selected.
• Print limitations: Some print formatting options are not supported in HTML (kerning, tracking, and locking to the baseline are just a few examples).
The hours you spend adjusting and fine-tuning a layout for print are all but wasted when you convert the layout for web distribution.
• End-user variability: If you follow the rules when designing for print, every printed piece will look exactly the same when they come off the press (WYSIWYG). Designing for the web is not so static. The variables involved in web distribution — including different platforms, monitors, and browsers used by the end consumer — mean that what you see and what they see might be entirely different.

With the inherent differences between print and digital media, there is no instant solution to converting print design to web design. Using the tools built into DTP programs, however, smoothes many of the bumps along the road.

Behind the scenes – Proofreading

The proofreading stage of a translation project involves much more than checking for typographical errors. Excel Translations projects, for example, go through several rounds of proofreading after formatting (typesetting) is completed.

Mechanical proofreading compares the source to the target, checking for completion, proper font display, graphics, and general layout. This task is done by an experienced person with a great eye for detail. Often the proofreader finds things worth questioning for a linguist. For example, he/she might find two different translations for the same source word, such as “Warning”. The linguist will be asked to clarify or correct it.

Linguistic proofreading is done by a native speaker of the language, who checks not only for spelling, grammar, etc. but also for readability and style. The proofreader will also detect any inconsistencies in terminology.

After the typesetter has implemented all the corrections found during proofreading, then another review of the translation is done. This is done by the same mechanical proofreader. First, he/she checks that all the corrections are implemented properly and that any linguistic questions are handled. Often a mechanical proofreader is checking several languages for one project, and may detect patterns among the translations and may request further corrections for consistency….which are also verified on the next round.

This specific focus on different types of proofreading yields extremely high quality translations.

The United States officially becoming a bilingual nation?

Immigration has been a hot topic in the United States for decades. In fact, it’s probably safe to say it has been a point of discussion, as well as contention, for all of the nation’s history. This day in age, when people mention immigration, it’s usually safe to bet they’re referring to the Mexican population. Hispanics and Latinos, meaning anyone with origins in the Hispanic countries of Latin America or Spain, comprise the largest minority group in the country, at around 16% of the total U.S. population. Over the past 20 years, as this population has continued to steadily rise, economists and statisticians have predicted an ever increasing Hispanic influence on American culture; most notably, there is a belief that Spanish will one day become the nation’s second official language after English, much like Canada, who observes both English and French as official languages.

As will generally accompany change of any sort, there has been a great deal of controversy on whether the United States should or could become a technically bilingual nation. It is a headline that comes and goes, never really offering a concrete assertion as to when this abstract idea might eventually manifest.

But on July 6, 2011, the New York Times published an article by author Damien Cave describing reasons that Mexican emigration to the U.S. is decreasing. This informative piece caught many a critical eye due to its appearance in both English as well as Spanish. Ameena Schelling of The Daily Caller, a political news website based out of Washington D.C., commented “The decision to provide an article on such a contentious issue as immigration in a language so closely tied to the conflict raises questions about the intent of the coverage, as well as about the future possibilities of bilingual coverage in foreign bureaus.”

The fact of the matter is Cave set out to reach the vast audience he imagined would find his article relevant. Indeed, there is a broad enough population of Spanish speakers in the U.S. to make a bilingual publication worth his while. The implication is: though an argument on immigration laws may be becoming less and less relevant, the United States’ existing Hispanic and Latino population is evidently becoming more so.

Do Translations Become Outdated?

Does a translation need to be updated every few years? Perhaps your product has a user manual that was translated over ten years ago... does that mean that the translation is "old?" A translation for a user manual can generally last as long as the device does. If no user interface has changed or the workings of the device haven't changed at all, why should the instructions to use that device change? Indeed, as long as the original written instructions for use remain the same, the translations of the instructions won't need any revision.

Nonetheless, review and revision of translations is always important. Whenever a new document is released, it is the translator's duty to review the unchanged text alongside the new text to ensure that all text is appropriate for current use. With new emerging technology new terminology can emerge and languages may have established new ways of translating these words. It cannot be assumed a phrase will always be translated in the same way. Translators will check source text against the previous translations to look for consistency but they sometimes find the old text should be changed. Often when they report that a previous translation should be changed, it is because modern conventions have changed. Perhaps old terminology has fallen out of favor and newer terms are preferred. It would be convenient if language were static and could consistently relied upon but adhering to modern usage is always important.

So, in general, your translation will have "staying power" but should always be reviewed to ensure that it is still relevant. As long as your device is not "ancient," your translation shouldn't be either.