|
Today I received an email with a spreadsheet containing the "Final Pricing" for a client from an Account Manager at SimulTrans. We have worked this this customer for over 10 years, and I do not believe today's pricing spreadsheet is any more final than its dozens of predecessors. Like most of SimulTrans' customers, this client often requests new languages and services while also being subjected to the ebb and flow of localization costs as they are affected by currency exchange rates, competitive pressures, and negotiation savvy.
I decided to write about this "final" pricing spreadsheet not to highlight that rates can change, but to make the point that it is always a bad idea to label any file as "final." I see this moniker used in source files from customers, cost estimates we develop for prospective clients, project schedules from SimulTrans' project managers, and even some deliveries sent at the end of projects.
The Risk of "Final" Source Files
It is easy to label a file as "final." It always gives a nice sense of relief to add the title. "Phew, I finished the User's Guide and delivered the final files." Unfortunately this sense of completion and accomplishment often wanes quickly when a feature gets dropped at the last moment before release, a technical support URL changes, or a new screen capture must be inserted because of a small UI tweak. Just as quickly as your files were marked as "final," their finality ended. Now, you will probably need to create a file called "UserGuideFINAL2" or "UserGuideFinalB" or "UserGuide_MayRev." The problem is that your previously "final" file may be still floating around and people may actually assume it was final when sending it to the printer, uploading it to SimulTrans for localization, or posting it on your company's website.
Localization is particularly prone to false "final" documents. We receive materials with these markings all the time from clients. It is difficult to track which are truly the latest files. While we try to accomplish this through appropriately named source directories and rigorous version control standards, files with "final" in their names still can throw anyone off.
Recommended Directory and File Naming Convention
For any source files you plan to provide for localization, I recommend storing them in directories named based on the date. For example, you might have a directory for "UserGuide_20110428" and then one for an updated version named "UserGuide_20110510" today. By changing the directory/folder names you can keep track of which versions you have provided for localization and avoid needing to change individual filenames, which can cause problems with links between files and reduce leveraging of already completed translations.
The dates I recommend appending to the directory names (or filenames if dealing with individual files instead of big source directories) are formatted in yyyymmdd format. It does seem strange to list the year first, but doing this allows you to sort the files in the directory in chronological order easily so you can always find the most current at the top or bottom (depending on your choice of ascending or descending sort order).
Just as we ask you to avoid "final" files, SimulTrans will strive to avoid sending you a "final" proposal or "final" schedule, since we know these evolving project documents are never truly final. |
