Trabalhando com localidades personalizadas
Este tópico fornece algumas instruções para lidar com localidades personalizadas em seus aplicativos. É melhor preparar todo o código-fonte com essas considerações em mente, pois seu aplicativo não controla se as localidades personalizadas estão instaladas no sistema operacional.
Manipular LOCALE_STIME constante corretamente
Se você tiver um aplicativo mais antigo que usa GetLocaleInfo para obter o separador de tempo obsoleto indicado por LOCALE_STIME, o aplicativo poderá falhar ao analisar o formato de tempo. Lembre-se de que o caractere que separa horas de minutos é distinto do caractere que separa minutos de segundos.
Observação
Ao programar para localidades personalizadas, lembre-se de que elas são incomuns. Praticamente todos os campos disponíveis para NLS precisam lidar com comportamentos incomuns. Por exemplo, o formato de hora 12H34'12'' é legítimo e geralmente compreensível. No entanto, muitos aplicativos fazem suposições sobre os separadores de tempo que podem quebrar os comprimentos do buffer ou os campos de exibição.
Distinguir entre localidades suplementares
Todas as localidades complementares usam a constante LOCALE_CUSTOM_UNSPECIFIED para o identificador de localidade. Como regra, GetLocaleInfo não pode distinguir entre localidades suplementares, mas GetLocaleInfoEx pode porque usa nomes de localidade em vez de identificadores de localidade. Seu aplicativo pode recuperar informações sobre uma localidade complementar específica somente quando essa localidade for a localidade de usuário selecionada no momento. Em seguida, o aplicativo pode chamar GetLocaleInfo e passar a constante LOCALE_USER_DEFAULT como o identificador de localidade.
Manipular localidades de substituição
Para preservar a confiabilidade do Windows, lembre-se de que uma localidade de substituição compatível com seu aplicativo não pode modificar o identificador de localidade da localidade substituída. Nem uma localidade de substituição pode modificar as propriedades de classificação do Windows.
Embora uma localidade de substituição possa alterar o calendário padrão, ela deve manter o padrão original em algum lugar na lista de calendários disponíveis. Por exemplo, a localidade tailandesa (Tailândia) usa o calendário budista tailandês como padrão. Um administrador pode criar uma localidade de substituição que usa o calendário localizado gregoriano. No entanto, a lista de calendários disponíveis continua a conter uma entrada para o calendário budista tailandês.
Para localidades de substituição, seu aplicativo geralmente deve consultar informações específicas da localidade em vez de tentar um "atalho" com base no conhecimento de uma determinada localidade. Por exemplo, quando GetThreadLocale recupera a localidade atual como inglês (Estados Unidos), pode realmente ser uma localidade de substituição que deve ter permissão para entrar em vigor.
Personalizar Calendários
Seus aplicativos podem personalizar nomes de dias e meses para calendários gregorianos, mas não para calendários não gregorianos. Da mesma forma, o NLS não dá suporte à criação de calendários personalizados definidos pelo usuário. Para obter mais informações, consulte Data e Calendário.
Manipular sequências de classificação
Uma localidade complementar pode usar qualquer sequência de classificação definida pela Microsoft. Uma localidade de substituição deve usar a mesma sequência de classificação que a localidade que ela substitui. O NLS não dá suporte à criação de sequências de classificação definidas pelo usuário. Para obter mais informações, consulte Manipulando a classificação em seus aplicativos.
Localizar informações de localidade personalizada
O NLS não fornece um mecanismo para localizar informações de localidade personalizadas. Assim, a constante LOCALE_SLANGUAGE ou LOCALE_SLOCALIZEDLANGUAGENAME usada como um identificador de localidade para uma localidade personalizada sempre recupera valores associados a LOCALE_SNATIVELANGNAME ou LOCALE_SNATIVELANGUAGENAME.
Tópicos relacionados