Server Message Block Protocol (SMB protocol)

The Server Message Block Protocol (SMB protocol) provides a method for client applications in a computer to read and write to files on and to request services from server programs in a computer network. The SMB protocol can be used over the Internet on top of its TCP/IPprotocol or on top of other network protocols such as Internetwork Packet Exchange andNetBEUI. Using the SMB protocol, an application (or the user of an application) can access files at a remote server as well as other resources, including printers, mailslots, and named pipes. Thus, a client application can read, create, and update files on the remote server. It can also communicate with any server program that is set up to receive an SMB client request.

Microsoft Windows operating systems since Windows 95 include client and server SMB protocol support. For UNIX systems, a shareware program, Samba, is available. The SMB protocol originated at Microsoft and has gone through a number of developments. A given client and server may implement different sets of protocol variations which they negotiate before starting a session.

Microsoft has offered a public or open source version of SMB for the Internet to the Internet Engineering Task Force (IETF). Called the Common Internet File System (CIFS), this new protocol provides more flexibility than existing Internet applications such as the File Transfer Protocol (FTP). CIFS is envisioned as a complement to the Internet's Hypertext Transfer Protocol for Web browsing.

10 tips and best practices for software localization

By Guest contributor

Takeaway: Localizing your software can be an exercise in frustration. Avoid major headaches by following this practical advice.

Many companies seek to expand their business and provide software products for the worldwide market through localization (L10N) — translating or adapting a software product into different languages or for a specific country or region. Many localization attempts are met with frustration once the software is built: Text is garbled, fonts aren't exact, encoding of exotic languages doesn't look right, sentences are cut off, and in general, software builds may not work as designed.

Here are some pointers to help you avoid these problems and produce a quality product for the global market.

1: Plan ahead

For many companies, software localization turns out to be a last-minute rush before a product release.  All localization scheduling and scoping efforts should take into account the translation, testing, and regression that must occur to produce a quality product.

2: Test your software

In most cases, localized software should be tested as rigorously as the original English software. There's no replacement for the awareness that comes with seeing a foreign language "in context" within your software.

3: Develop a detailed English test plan

Use this same test plan in your localized testing. The same crucial UI dialogs and functionality will be put to the test. Reusing the English test plan for localization testing is common in the industry and will avoid delays in L10N testing.

4: Leave plenty of space for text expansion in other languages

Many languages take up to 30 percent more space than English! If your engineers design the software for which English "just barely fits," you'll have a problem down the road. Leave ample space or program dynamic UI expansion into your software.

5: Use localization-friendly encoding of strings

When possible, source your string tables or software resources in Unicode/UTF-8 encoding. This will avoid extra conversion steps, time-consuming debug work, and garbled text.

6: Perform "pseudo localization" to root out hard-coded strings

In a separate temporary branch, use a regular expression to replace all letters in the string textwith a single repeating character, such as "XXXXX." Build the software, and any hard-coded text will really jump out at you, showing string IDs that are not defined in string tables.

7: Avoid concatenation and overuse of single strings

A combination of words in English will most likely not follow the same order in most other languages. Concatenated strings and strings that are used in multiple contexts will have grammar and gender agreement issues. Gone are the days of optimizing software due to memory limitations, so be generous when localizing your product.

8: Provide "internationalization" support in your software (i18n)

This will enable dates, numbers, and other region-specific data such as currency to show up in a familiar and comfortable way to all users around the world.

9: Provide numerous comments in software resources that define context

Knowing the context and use of certain strings will help translators choose the right translation from the beginning. Most translation tools will allow translators to see these comments as they translate the strings.

10: Perform localization of Help and software (GUI) at the same time

Users around the world will notice when context-sensitive help tells them to click on a button that is worded differently in the software itself. Seek a responsible and experienced translation company to handle both your software and Help/User's Guide at the same time to ensure consistency between your software and help documentation.

About the authors

Jeremy Coombs is senior vice president of operations for translation service provider MultiLing, managing large-scale translation and localization projects for companies such as Dell, LSI Corporation, Qlogic, Intuit, and GE Healthcare.