Creating form fields
When creating forms for submitting data, make your forms as generic as possible. The less mandatory your forms are, the better. Creating forms with overly specific, American-oriented categories may confuse users in other countries, and thus limit your ability to communicate internationally.
Here is a form on the website of a fictional American company, Chuzzlewit Brothers Chocolates.
The form was developed for the English-language site, but because the developer wants to maintain an international list of users in a single database table, she will utilize the same form (and by extension, database columns) for the site's localized pages.
When creating the above form, the web developer accounted for the following localization issues:
|
The text fields are set to accept a large number of characters. This will accommodate multi-part names, extra long addresses, and so forth. |
|
The phone field does not contain numerical guides, such as parentheses for area codes, or the dashes that customarily separate the first three digits of an American phone number from the last four digits. |
|
The postal code column in the database is set to the TEXT data type (not NUMBER), so that the database will accept alphanumeric values from the postal code field on the form. For example, the postal code for Buckinghamshire, England, HP10 0HH, would be rejected by the database if the corresponding database column were set to NUMBER. |
|
The country field is a drop-down menu, giving the user selective ability, and reducing the risk of user error. |
|
Lastly, none of the fields are mandatory. If the postal code field were mandatory, people in Hong Kong would not be able to complete the form. |
If you keep your form fields generic, your localizer will only have to alter the descriptive text on your form. The fields and corresponding database columns can remain the same.
|