Resource files can live anywhere in a project, but there are common practices in place that have proven to be successful. using IHost host = Host.CreateDefaultBuilder(args) This allows you to configure localization options. The AddLocalization(IServiceCollection, Action) overload accepts a setupAction parameter of type Action. This will enable dependency injection (DI) of the following types: To register localization services, call one of the AddLocalization extension methods during the configuration of services. Apply an assembly level attribute to correct this mismatch:
The example project is named example.csproj, which creates an example.dll and example.exe - however, the Localization.Example namespace is used. When provided, it is used during resource lookup. To address this mismatch, use the RootNamespaceAttribute to provide a hint to the localization services. This can prevent resource lookup from being otherwise successful. If your project file name is different than the root namespace of your project, the assembly name might differ. Resource files are automatically resolved as part of a lookup routine. For more information, see The resource fallback process. If the culture was set to "fr-FR", localization would end up falling to the MessageService.resx file which can be problematic. The "culture fallback" rule will ignore locales when there are no corresponding matches, meaning resource file number four is selected if it's unable to find a match. However, if your app was running with the CultureInfo.CurrentCulture set to a culture of "sr-Latn-BA" localization attempts to resolve files in the following order: When your app is running with the CultureInfo.CurrentCulture set to a culture of "sr-Cyrl-RS" localization attempts to resolve files in the following order: Imagine that your localized app supports various Serbian locales, and has the following resource files for its MessageService: File For more information, see CultureInfo.Name.
The locale should map to a well-known language tag. With the added specificity of a culture, the "culture fallback" rules are applied where best matches are prioritized.
These segments are commonly delimited by the - character. The locale should define the language, at a bare minimum, but it can also define the culture (dialect), and even the country or region. The optional represents the locale of the resource file contents.The represents localizable resources for a specific type.A resource file name most commonly contains a locale identifier, and takes on the following form: Resource files are translated prior to the execution of the consuming application - in other words, they represent translated content at rest. The primary mechanism for isolating localizable strings is with resource files.
#Keyword localizer code#
All of the example source code in this article relies on the and NuGet packages.
#Keyword localizer how to#
In this article, you will learn how to use the IStringLocalizer and IStringLocalizerFactory implementations. The combination of a localized version of the user interface block with the code block produces a localized version of your application. The code block for all cultures should remain the same. NET.įor each localized version of your application, add a new satellite assembly that contains the localized user interface block translated into the appropriate language for the target culture. For more information about implementing this model, see Resources in. The common language runtime supports a satellite assembly resource model that separates an application's executable code from its resources. The code block contains only the application code to be used by all supported cultures. The user interface block contains only localizable user-interface elements such as strings, error messages, dialog boxes, menus, embedded object resources, and so on for the neutral culture. You should proceed to the localization step only after completing the Localizability review step to verify that the globalized application is ready for localization.Īn application that is ready for localization is separated into two conceptual blocks: a block that contains all user interface elements and a block that contains executable code. Localization is the process of translating an application's resources into localized versions for each culture that the application will support.
0 kommentar(er)
