By Allen Alexander,2014-06-03 14:20
10 views 0


    1)Encoding – check if the web-pages or any file type that is sent to and from our web-site/service

    always has the UTF-8 encoding. This is as basic as apple in apple pie. (G1)

    2)CultureInfo object with a hard-coded locale. Check if the CultureInfo object’s constructor has

    either a hard-coded LCID (e.g. 1033) or a culture name (en-US). This is typically an indication

    that the code has some functionality that is hard-wired to that the culture. (G2)3)Misuse of CurrentCulture, UICulture, InvariantLocale – check if the code is using the wrong

    culture for certain operations, especially string.Format(). (G3)

    4)Hard-coded date-time formatting. Check if any DateTime class is used with a hard-coded format

    to display to the end-user and that no custom string formatting is done that assumes the date

    format is mm/dd/yyyy. (G4)

    5)Hard-coded start of week-day. Different locales use different start of week day. Monday is not

    always the first start of day. (G5)

    6)Hard-coded currency formats. Check if the code is assuming a hard-coded currency ‘$’ for e.g.


    7)Hard-coded number formats. Check if the code is assuming the number separator used to format

    currency is ‘,’ or any other hard-coded separator. (G7)

    8)String.Compare () - Turkish-I issue – check if the code is doing a culture-sensitive string

    comparison on string literals. The comparison will break on Turkish and Azeri locales if the

    strings compared have different uppercase and lowercase ‘I’s. (G8)

    9)ToUpper() and ToLower() – same issue as (f). See if the code is doing this using the default thread

    culture – string.ToUpper()/ToLower() calls without any parameters. (G9)

    10)Dictionary<> or Hashtable instances that use a string as the key. If the keys are case-insensitive

    then we need to make sure the appropriate StringComparer is used. (G10)

    11)Sorting of user-facing data – check if code is doing a culture-neutral sort of any data that is

    displayed to the user. This would make for a very annoying end-user experience – just imagine a

    phone book sorted in random order. (G11)

    12)Sorting of internal data – check if the code is doing a culture-sensitive sort – this will be

    definitely not the right thing to do as we always want the data sorted the same way irrespective of

    the locale of the end-user. (G12)

    13)Ascii support only – check if the code has any logic that assumes all end-user input is ASCII only.

    For e.g.: if you see a regular expression of the sort [a-zA-Z] that should raise a red flag. (G13)14)Mirroring issues – this is a can of worms… I need to dig up more on this. Later. (G14)15)Using fixed sized buffers for end-user text – assuming that text (user name for example) can

    never be more than a certain limit will be broken on some languages (German for example) where

    strings typically are more than their English equivalents. (G15)

    SQL Globalization:

    1)SQL data types – usage of char, varchar, text in sql instead of the Unicode types nchar, nvarchar

    and ntext. Non-unicode types are code-page dependent and will result in lossy round-tripping of

    data when converted from Unicode to their ANSI equivalents. This especially affects Unicode-

    only languages like Indic, Tibetan, etc. Also, code-pages are set in stone and are not updated so

    new code-points in the Unicode repertoire will not be handled because of this. (S1)2)SQL collation – check sorting of any data returned from stored procedures is in the user’s locale.

    Review all “GROUP BY” “ORDER BY” “DISTINCT” sql statements. These will probably need

    to use the COLLATE keyword to sort the returned data in the user’s locale. Also MAX, MIN,

    BETWEEN, LIKE, and IN operators are collation-sensitive. (S2)

    3)Hard-coded date-time formatting – check if stored procedures return date-times in short format.

    This can be problematic if the format is hard-coded. (S3)


    1)Hard-coded strings – check if the code has any hard-coded user-facing strings. “Exception”

    strings may be an exception if they do not flow to any UI. If they flow to some logging

    mechanism then it is ok. Need to check this in both code and web-pages including .js files. (L1)2)Concatenating user-facing strings. Check if any user-facing strings are concatenated at runtime.

    This will be broken on non-english speaking locales if the strings come from resources and they

    will not make any sense whatsoever to the end-user. (L2)

    3)Hard-coding font-face names is a complete no-no. Not all fonts support all scripts so we need to

    make sure the code/aspx page doesn’t use any hard-coded font face names while rendering any

    data to the user. (L3)

    4)Hard-coded control sizes both in code and aspx files – these will cause truncations if text grows

    beyond control size. (L4)

    5)User facing strings in xml/xslt files. These can be a royal pain in the butt to localize as we need to

    tell the localization tool what specific attributes and what elements are localizable and they must

    all have unique ids. If the schema doesn’t support IDs then the only option is to move it to a

    format that supports ids or just simply move them to a resx file. (L5)

    6)Strings in file formats that are not easily localizable. Check if we are loading user-facing strings

    from text files that use a custom format, etc. (L6)

    7)Hard-coded strings in images would be huge problem from a localizability perspective. It is a big

    no-no. (L7)

    8)Using display strings for internal logic. If we are assuming in code a certain value that is

    displayed to the user in a list for example then this would be broken once the strings are localized.


    9)Using single word strings that are all in lower case in resources. This is a definite no-no from a

    localizability perspective as they are hard to localize without enough context on how they are

    used. (L9)

    10)Using hard-coded FWLinks – these need to change on a per-market basis. If these are in code or

    in ASPX files then these cannot be updated. (L10)

    11)Non-localizable strings in localizable resources (.resx files). If the strings are not localizable then

    they don’t belong in the resources. Resource files must be scrubbed to ensure we don’t have any

    non-localizable strings in them especially if these are internal program constants that don’t

    change from locale to locale. (L11)

    12)Review every resource string to make sure there are no assumptions as to the format of the string

    in localized versions – for .e.g expecting that the number of commas in the localized string is the

    same as in the source English string. Basically the changing the resource string should not result

    in any functional break in the product. You will need to review both the code and the associated

    resource string. (L12)

    13)Inline css styles on elements in dynamic web-pages can cause localizability problems.

    Since.aspx/.ascx files are not localized inline style definitions on individual elements should be

    moved to a central .css file so they can be localized independently. (L13)


    1)Hard-coded market specific string (M1). Examples of these include support URLs, support web-

    pages or anything that could potentially be market specific.

Report this document

For any questions or suggestions please email