Actually, Tadman brings up a good point, for the techniques that allow for rapid and flexible localization can greatly assist visual re-branding efforts as well. After all, if your logo is a resource and it changes, well, change the resource and you're done.
I've previously mentioned that I used to work for a commercial software vendor. Everything sold locally was translated into multiple languages and character sets. This was frequently a difficult task for the International team and they spent significant time and energy trying to teach the U.S.-based teams how to best make the localization process as painless as possible. Here's a set of guidelines (slightly amended with additional notes from my experience) they once distributed in the form of bookmarks:1
Character Sets:
Use relevant API's and locale aware libraries for character manipulation and classification when appropriate. (Note: this should include specifying character encoding whenever possible.) Remember that there may be differences between the end-user's machine/environment, the operating system running the program, and the server handling the data.
This may include issues like character conversion (and loss), alternate sorting patterns, the direction of text, and extended characters.
Data Formats (Numeric, Date, Currency):
Be prepared to support alternate separators, symbols, and formats. Also, be aware that "standard" data arrangement may change from country to country. Example: Placement of the country in an address block, as well as the name of the postal/routing code.
Expansion for Translation:
Allow room for expansion, especially in displayed strings and buffer sizes. Use dynamically resized buffers whenever possible. Add overflow, underflow, and overrun checks.
Core International Tests:
Include a core set of internationally-enabled tests in core QA. (Meaning, don't always perform unit testing with straight ASCII/ANSI/UTF-8. Make sure automated tests include alternate character sets, different data formats, and localized strings--including characters unique to the alternate character sets.)
Separate Resource Libraries:
Use separate resource-only libraries (modules or DLL's, depending on the environment) for all translatable components, including text, coordinates, and font definitions. (Note: this should also include any image data, such as colors and graphics (JPG's, GIF's, or BMP's).
Also, remember that different cultures respond differently to abstract images differently. Simple example: Stop signs. Colors mean different things to different cultures.
No Dynamic Concatenation:
Sentence structure changes internationally. Use string formatting functions, replaceable parameters, and lookup tables.
Duplicate Resourced Keywords:
Allow for the use of either English or localized keywords; let the user choose.
Now, yes, this was originally developed by a company that worked with Windows and DOS based operating systems; however, the same issues apply to Perl CGI scripts, HTML, and (AFAIK) just about any other technical production environment that might cross borders.
Also, name changes and re-branding efforts aren't limited to start-ups, you know. I've seen them happen in:
Established companies: The last company I worked for had been purchased by another just before I started. Eventually, the new owners decided to "rebrand" all the products produced by their subsidiaries to incorporate their company name. This included logo changes. Since I was working on financial calculation software, it meant extensive changes throughout the product, including bitmap changes, textual changes on the GUI, report modifications, Help file updates, installation modifications (including supporting utilities), and so on.
(Naturally, the new owner was in turn bought by a third-company about six months after we finally managed to get everything rebranded--and the software retrofitted to support future changes. Guess what the new owners wanted?)
Commercial software: Many companies in this segment use code names for their products up until the final build. It may eventually ship as Uber Widgit Deluxe, but until marketing can obtain a trademark (which can be a long, arduous process), you have to refer to it as "Foo." As you might expect, this affects information displayed to the user, supporting documentation (whether source for printed manuals or POD), and a number of other items.
Consultancies: Many consultancies develop shared libraries and application frameworks to help them develop software more quickly. This lets them reuse many elements with different clients. However, you have to be careful developing these, for it can take as long to "convert" AlphaCorp's contact management database for BetaBiz.
On the flip side, a properly designed framework can make this conversion effort a breeze. In my experience, frameworks designed with international issues in mind tend to be easier to visually re-brand than those developed with a single set of idioms and standards.(I'm sure there are many other cases; these are just the ones I've run into during my career.)
In short, planning can make a tremendous amount of difference in many areas.
--f
Footnotes:
1 - By bookmark, I mean a small piece of laminated paper one uses to mark one's location in a paper book, not those virtual shortcuts one stores in their browser to flag interesting (or plain wierd) sites on the 'Net.
In reply to Re: Planning ahead for product name changes
by footpad
in thread Planning ahead for product name changes
by dws
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |