Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Warning
Den här versionen av ASP.NET Core stöds inte längre. Mer information finns i supportpolicyn för .NET och .NET Core. För den nuvarande utgåvan, se .NET 9-versionen av den här artikeln .
Important
Den här informationen gäller en förhandsversionsprodukt som kan ändras avsevärt innan den släpps kommersiellt. Microsoft lämnar inga garantier, uttryckliga eller underförstådda, med avseende på den information som tillhandahålls här.
För den nuvarande utgåvan, se .NET 9-versionen av den här artikeln .
Av Rick Anderson, Damien Bowden, Bart Calixto, Nadeem Afana och Hisham Bin Ateya
En flerspråkig webbplats gör det möjligt för en webbplats att nå en bredare publik. ASP.NET Core tillhandahåller tjänster och mellanprogram för att lokalisera till olika språk och kulturer.
Vägledning Blazor om lokalisering, som lägger till eller ersätter vägledningen i den här artikeln, finns i ASP.NET Core Blazor globalisering och lokalisering.
Terms
- Globalisering (G11N): Processen för att skapa en app stöder olika språk och regioner. Förkortningen kommer från de första och sista bokstäverna och antalet bokstäver mellan dem.
- Lokalisering (L10N): Processen att anpassa en globaliserad app för specifika språk och regioner.
- Internationalisering (I18N): Både globalisering och lokalisering.
- Kultur: Ett språk och, om du vill, en region.
- Neutral kultur: En kultur som har ett angivet språk, men inte en region (till exempel "en", "es").
- Specifik kultur: En kultur som har ett angivet språk och en angiven region (till exempel "en-US", "en-GB", "es-CL").
- Överordnad kultur: Den neutrala kultur som är ursprunget till en specifik kultur (till exempel, "en" är den överordnade kulturen av "en-US" och "en-GB").
- Nationella inställningar: Ett språk är samma som en kultur.
Språk- och lands-/regionkoder
              RFC 4646-formatet för kulturnamnet är <language code>-<country/region code>, där <language code> identifierar språket och <country/region code> identifierar subkulturen. Till exempel es-CL för spanska (Chile), en-US för engelska (USA) och en-AU för engelska (Australien). 
              RFC 4646 är en kombination av en ISO 639-kod med två små bokstäver som är associerad med ett språk och en ISO 3166-kod med två stora bokstäver som är associerad med ett land eller en region. Mer information finns i System.Globalization.CultureInfo.
Arbetsuppgifter för att lokalisera en app
Globalisering och lokalisering av en app omfattar följande uppgifter:
- Gör en ASP.NET Core-appens innehåll lokaliserat.
- Tillhandahålla lokaliserade resurser för de kulturer som appen stöder
- Implementera en strategi för att välja kultur för varje begäran
Visa eller ladda ned exempelkod (hur du laddar ned)
Ytterligare resurser
- Url-kulturprovider med mellanprogram som filter i ASP.NET Core
- Tillämpa RouteDataRequest CultureProvider globalt med mellanprogram som filter
- 
              IStringLocalizer: Utnyttjar ResourceManager och ResourceReader för att tillhandahålla kulturspecifika resurser under körning. Gränssnittet har en indexerare och enIEnumerableför att returnera lokaliserade strängar.
- 
              IHtmlLocalizer: För resurser som innehåller HTML.
- Visa och DataAnnotationer
- Felsöka ASP.NET Core-lokalisering
- Globalisera och lokalisera .NET-program
- Resurser i .resx-filer
- Lokalisering & Generiska
Av Rick Anderson, Damien Bowden, Bart Calixto, Nadeem Afana och Hisham Bin Ateya
En flerspråkig webbplats gör det möjligt för en webbplats att nå en bredare publik. ASP.NET Core tillhandahåller tjänster och mellanprogram för att lokalisera till olika språk och kulturer.
Terms
- Globalisering (G11N): Processen för att skapa en app stöder olika språk och regioner. Förkortningen kommer från de första och sista bokstäverna och antalet bokstäver mellan dem.
- Lokalisering (L10N): Processen att anpassa en globaliserad app för specifika språk och regioner.
- Internationalisering (I18N): Både globalisering och lokalisering.
- Kultur: Ett språk och, om du vill, en region.
- Neutral kultur: En kultur som har ett angivet språk, men inte en region (till exempel "en", "es").
- Specifik kultur: En kultur som har ett angivet språk och en angiven region (till exempel "en-US", "en-GB", "es-CL").
- Överordnad kultur: Den neutrala kultur som är ursprunget till en specifik kultur (till exempel, "en" är den överordnade kulturen av "en-US" och "en-GB").
- Nationella inställningar: Ett språk är samma som en kultur.
Språk- och lands-/regionkoder
              RFC 4646-formatet för kulturnamnet är <language code>-<country/region code>, där <language code> identifierar språket och <country/region code> identifierar subkulturen. Till exempel es-CL för spanska (Chile), en-US för engelska (USA) och en-AU för engelska (Australien). 
              RFC 4646 är en kombination av en ISO 639-kod med två små bokstäver som är associerad med ett språk och en ISO 3166-kod med två stora bokstäver som är associerad med ett land eller en region. Mer information finns i System.Globalization.CultureInfo.
Arbetsuppgifter för att lokalisera en app
Globalisering och lokalisering av en app omfattar följande uppgifter:
- Gör en ASP.NET Core-appens innehåll lokaliserat.
- Tillhandahålla lokaliserade resurser för de kulturer som appen stöder
- Implementera en strategi för att välja kultur för varje begäran
Visa eller ladda ned exempelkod (hur du laddar ned)
Ytterligare resurser
- Gör innehållet i en ASP.NET Core-app localizable
- Tillhandahålla lokaliserade resurser för språk och kulturer i en ASP.NET Core-app
- Strategier för att välja språk och kultur i en lokaliserad ASP.NET Core-app
- Felsöka ASP.NET Core-lokalisering
- Globalisera och lokalisera .NET-program
- Localization.StarterWeb-projekt som används i artikeln.
- Resurser i .resx-filer
- Lokalisering & Generiska
Av Rick Anderson, Damien Bowden, Bart Calixto, Nadeem Afana och Hisham Bin Ateya
Med en flerspråkig webbplats kan webbplatsen nå en bredare publik. ASP.NET Core tillhandahåller tjänster och mellanprogram för att lokalisera till olika språk och kulturer.
Internationalisering omfattar System.Globalization och lokalisering. Globalisering är processen att utforma appar som stöder olika kulturer. Globalisering lägger till stöd för indata, visning och utdata för en definierad uppsättning språkskript som relaterar till specifika geografiska områden.
Lokalisering är processen att anpassa en globaliserad app, som du redan har bearbetat för lokaliserbarhet, till en viss kultur/nationella inställningar. Mer information finns i Globaliserings- och lokaliseringsvillkor i slutet av det här dokumentet.
Applokalisering omfattar följande:
- Gör appens innehåll lokaliserat
- Tillhandahålla lokaliserade resurser för de språk och kulturer som du stöder
- Implementera en strategi för att välja språk/kultur för varje begäran
Visa eller ladda ned exempelkod (hur du laddar ned)
Göra appens innehåll lokaliserat
              IStringLocalizer och IStringLocalizer<T> har utvecklats för att förbättra produktiviteten när lokaliserade appar utvecklas. 
              IStringLocalizer använder både ResourceManager och ResourceReader för att tillhandahålla kulturspecifika resurser vid körning. Gränssnittet har en indexerare och en IEnumerable för att returnera lokaliserade strängar. 
              IStringLocalizer kräver inte lagring av standardspråksträngarna i en resursfil. Du kan utveckla en app som är avsedd för lokalisering och inte behöver skapa resursfiler tidigt under utvecklingen. Koden nedan visar hur du omsluter strängen "Om rubrik" för lokalisering.
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Localization;
namespace Localization.Controllers
{
    [Route("api/[controller]")]
    public class AboutController : Controller
    {
        private readonly IStringLocalizer<AboutController> _localizer;
        public AboutController(IStringLocalizer<AboutController> localizer)
        {
            _localizer = localizer;
        }
        [HttpGet]
        public string Get()
        {
            return _localizer["About Title"];
        }
    }
}
I föregående kod kommer implementeringen IStringLocalizer<T> från Beroendeinmatning. Om det lokaliserade värdet "Om rubrik" inte hittas, returneras indexerarens nyckel, det vill säga strängen "Om rubrik". Du kan lämna standardsträngarna för språket i appen och omsluta dem i lokalisatorn, så att du kan fokusera på att utveckla appen. Du utvecklar din app med ditt standardspråk och förbereder den för lokaliseringssteget utan att först skapa en standardresursfil. Du kan också använda den traditionella metoden och ange en nyckel för att hämta standardspråksträngen. För många utvecklare kan det nya arbetsflödet med att inte ha en .resx-standardfil och bara omsluta strängliteralerna minska kostnaderna för att lokalisera en app. Andra utvecklare föredrar det traditionella arbetsflödet eftersom det kan göra det enklare att arbeta med längre strängliteraler och göra det enklare att uppdatera lokaliserade strängar.
Använd implementeringen IHtmlLocalizer<T> för resurser som innehåller HTML. 
              IHtmlLocalizer HTML kodar argument som är formaterade i resurssträngen, men som inte HTML-kodar själva resurssträngen. I exemplet nedan är endast värdet name för parametern HTML-kodat.
using System;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Localization;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.Localization;
namespace Localization.Controllers
{
    public class BookController : Controller
    {
        private readonly IHtmlLocalizer<BookController> _localizer;
        public BookController(IHtmlLocalizer<BookController> localizer)
        {
            _localizer = localizer;
        }
        public IActionResult Hello(string name)
        {
            ViewData["Message"] = _localizer["<b>Hello</b><i> {0}</i>", name];
            return View();
        }
Note
I allmänhet bör man endast lokalisera texten, inte HTML.
På lägsta nivån kan du få IStringLocalizerFactory ur beroendeinjektionen:
{
    public class TestController : Controller
    {
        private readonly IStringLocalizer _localizer;
        private readonly IStringLocalizer _localizer2;
        public TestController(IStringLocalizerFactory factory)
        {
            var type = typeof(SharedResource);
            var assemblyName = new AssemblyName(type.GetTypeInfo().Assembly.FullName);
            _localizer = factory.Create(type);
            _localizer2 = factory.Create("SharedResource", assemblyName.Name);
        }       
        public IActionResult About()
        {
            ViewData["Message"] = _localizer["Your application description page."] 
                + " loc 2: " + _localizer2["Your application description page."];
Koden ovan visar var och en av de två metoderna för att skapa fabrik.
Du kan partitionera dina lokaliserade strängar efter styrenhet, område eller bara ha en container. I exempelappen används en dummyklass med namnet SharedResource för delade resurser.
// Dummy class to group shared resources
namespace Localization
{
    public class SharedResource
    {
    }
}
Vissa utvecklare använder Startup klassen för att innehålla globala eller delade strängar. I exemplet nedan används InfoController- och SharedResource-lokalisatorerna:
public class InfoController : Controller
{
    private readonly IStringLocalizer<InfoController> _localizer;
    private readonly IStringLocalizer<SharedResource> _sharedLocalizer;
    public InfoController(IStringLocalizer<InfoController> localizer,
                   IStringLocalizer<SharedResource> sharedLocalizer)
    {
        _localizer = localizer;
        _sharedLocalizer = sharedLocalizer;
    }
    public string TestLoc()
    {
        string msg = "Shared resx: " + _sharedLocalizer["Hello!"] +
                     " Info resx " + _localizer["Hello!"];
        return msg;
    }
Visa lokalisering
Tjänsten IViewLocalizer tillhandahåller lokaliserade strängar för en vy. Klassen ViewLocalizer implementerar det här gränssnittet och hittar resursens plats utifrån sökvägen för vyfilen. Följande kod visar hur du använder standardimplementeringen av IViewLocalizer:
@using Microsoft.AspNetCore.Mvc.Localization
@inject IViewLocalizer Localizer
@{
    ViewData["Title"] = Localizer["About"];
}
<h2>@ViewData["Title"].</h2>
<h3>@ViewData["Message"]</h3>
<p>@Localizer["Use this area to provide additional information."]</p>
Standardimplementeringen av IViewLocalizer hittar resursfilen baserat på vyns filnamn. Det finns inget alternativ för att använda en global delad resursfil. 
              ViewLocalizer implementerar lokaliseraren med IHtmlLocalizer, så Razor HTML-kodar inte den lokaliserade strängen. Du kan parametrisera resurssträngar och IViewLocalizer HTML-koda parametrarna, men inte resurssträngen. Överväg följande Razor markup:
@Localizer["<i>Hello</i> <b>{0}!</b>", UserManager.GetUserName(User)]
En fransk resursfil kan innehålla följande:
| Key | Value | 
|---|---|
| <i>Hello</i> <b>{0}!</b> | <i>Bonjour</i> <b>{0} !</b> | 
Den renderade vyn skulle innehålla HTML-markering från resursfilen.
Note
I allmänhet bör man endast lokalisera texten, inte HTML.
Om du vill använda en delad resursfil i en vy matar du in IHtmlLocalizer<T>:
@using Microsoft.AspNetCore.Mvc.Localization
@using Localization.Services
@inject IViewLocalizer Localizer
@inject IHtmlLocalizer<SharedResource> SharedLocalizer
@{
    ViewData["Title"] = Localizer["About"];
}
<h2>@ViewData["Title"].</h2>
<h1>@SharedLocalizer["Hello!"]</h1>
Lokalisering av DataAnnotations
Felmeddelanden för DataAnnotations lokaliseras med IStringLocalizer<T>. Med alternativet ResourcesPath = "Resources"kan felmeddelandena i RegisterViewModel lagras i någon av följande sökvägar:
- Resources/ViewModels.Account.RegisterViewModel.fr.resx
- Resources/ViewModels/Account/RegisterViewModel.fr.resx
public class RegisterViewModel
{
    [Required(ErrorMessage = "The Email field is required.")]
    [EmailAddress(ErrorMessage = "The Email field is not a valid email address.")]
    [Display(Name = "Email")]
    public string Email { get; set; }
    [Required(ErrorMessage = "The Password field is required.")]
    [StringLength(8, ErrorMessage = "The {0} must be at least {2} characters long.", MinimumLength = 6)]
    [DataType(DataType.Password)]
    [Display(Name = "Password")]
    public string Password { get; set; }
    [DataType(DataType.Password)]
    [Display(Name = "Confirm password")]
    [Compare("Password", ErrorMessage = "The password and confirmation password do not match.")]
    public string ConfirmPassword { get; set; }
}
Attribut som inte är för validering är lokaliserade.
Använda en resurssträng för flera klasser
Följande kod visar hur du använder en resurssträng för valideringsattribut med flera klasser:
public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc()
        .AddDataAnnotationsLocalization(options => {
            options.DataAnnotationLocalizerProvider = (type, factory) =>
                factory.Create(typeof(SharedResource));
        });
}
I föregående kod SharedResource är klassen som motsvarar den resx där dina valideringsmeddelanden lagras. Med den här metoden kommer DataAnnotations endast att använda SharedResource istället för att använda resurser för varje klass.
Tillhandahålla lokaliserade resurser för de språk och kulturer som du stöder
SupportedCultures och SupportedUICultures
ASP.NET Core kan du ange två kulturvärden SupportedCultures och SupportedUICultures. Objektet CultureInfo för SupportedCultures avgör resultatet av kulturberoende funktioner, till exempel datum, tid, tal och valutaformatering. 
              SupportedCultures bestämmer också sorteringsordningen för text, höljekonventioner och strängjämförelser. Mer information om hur servern hämtar kulturen finns i CultureInfo.CurrentCulture och CultureInfo.CurrentUICulture. Avgör SupportedUICultures vilka översatta strängar (från .resx filer) som ska letas upp av ResourceManager. Letar ResourceManager upp kulturspecifika strängar som bestäms av CurrentUICulture. Varje tråd i .NET har CurrentCulture och CurrentUICulture objekt. Ramverket inspekterar dessa värden när kulturberoende funktioner återges. Om den aktuella trådens kultur är inställd på en-US (engelska, USA), DateTime.Now.ToLongDateString() visas Thursday, February 18, 2016; men om CurrentCulture är inställt på es-ES (spanska, Spanien) visas jueves, 18 de febrero de 2016.
Resursfiler
En resursfil är en användbar mekanism för att skilja lokala strängar från kod. Översatta strängar för det icke-standardspråket är isolerade i .resx-resursfiler . Du kanske till exempel vill skapa en spansk resursfil med namnet Welcome.es.resx som innehåller översatta strängar. "es" är språkkoden för spanska. Så här skapar du den här resursfilen i Visual Studio:
- Högerklicka på mappen som innehåller resursfilen >> i Solution Explorer.   
- I rutan Sök installerade mallar anger du "resurs" och namnger filen.   
- Ange nyckelvärdet (ursprunglig sträng) i kolumnen Namn och den översatta strängen i kolumnen Värde .   - Visual Studio visar filen Welcome.es.resx .   
Namn på resursfil
Resurser namnges efter det fullständiga typnamnet på deras klass minus assembly-namnet. Till exempel skulle en fransk resurs i ett projekt vars huvudsammansättning är LocalizationWebsite.Web.dll för klassen LocalizationWebsite.Web.Startup ha namnet Startup.fr.resx. En resurs för klassen LocalizationWebsite.Web.Controllers.HomeController skulle ha namnet Controllers.HomeController.fr.resx. Om målklassens namnområde inte är samma som sammansättningsnamnet behöver du det fullständiga typnamnet. I exempelprojektet skulle till exempel en resurs för typen ExtraNamespace.Tools ha namnet ExtraNamespace.Tools.fr.resx.
I exempelprojektet anger metoden ConfigureServicesResourcesPath till "Resurser", så den relativa projektsökvägen för hemmkontrollerns franska resursfil är Resources/Controllers.HomeController.fr.resx. Du kan också använda mappar för att ordna resursfiler. För hemstyrenheten skulle sökvägen vara Resurser/Styrenheter/HomeController.fr.resx. Om du inte använder ResourcesPath alternativet går .resx-filen i projektbaskatalogen. Resursfilen för HomeController skulle ha namnet Controllers.HomeController.fr.resx. Valet att använda punktnotation eller sökvägsnotation som namngivningskonvention beror på hur du vill organisera dina resursfiler.
| Resursnamn | Namngivning av punkt eller sökväg | 
|---|---|
| Resources/Controllers.HomeController.fr.resx | Dot | 
| Resources/Controllers/HomeController.fr.resx | Path | 
Resursfiler som använder @inject IViewLocalizer i Razor vyer följer ett liknande mönster. Resursfilen för en vy kan namnges med antingen punktnamngivning eller sökvägsnamngivning. 
              Razor visa resursfiler som efterliknar sökvägen till deras associerade vyfil. Förutsatt att vi anger ResourcesPath till "Resurser" kan den franska resursfilen som är associerad med Views/Home/About.cshtml vyn vara något av följande:
- Resurser/vyer/Home/About.fr.resx 
- Resurser/vyer.Home. About.fr.resx 
Om du inte använder ResourcesPath alternativet finns .resx-filen för en vy i samma mapp som vyn.
RootNamespaceAttribute
Attributet RootNamespaceAttribute tillhandahåller rotnamnområdet för en sammansättning när rotnamnområdet för en sammansättning skiljer sig från sammansättningsnamnet.
Warning
Detta kan inträffa när ett projekts namn inte är en giltig .NET-identifierare. Till exempel my-project-name.csproj använder rotnamnområdet my_project_name och sammansättningsnamnet my-project-name som leder till det här felet.
Om rotnamnområdet för en sammansättning skiljer sig från sammansättningsnamnet:
- Lokalisering fungerar inte som standard.
- Lokaliseringen misslyckas på grund av sättet resurser söks efter i samlingen. 
              RootNamespaceär ett byggtidsvärde som inte är tillgängligt för den exekverande processen.
Om RootNamespace skiljer sig från AssemblyName, inkludera följande i AssemblyInfo.cs (med parametervärden ersatta med de faktiska värdena):
using System.Reflection;
using Microsoft.Extensions.Localization;
[assembly: ResourceLocation("Resource Folder Name")]
[assembly: RootNamespace("App Root Namespace")]
Föregående kod möjliggör en lyckad lösning av resx-filer.
Kulturåterställningsbeteende
När du söker efter en resurs ägnar sig lokaliseringen åt "kulturåterställning". Från den begärda kulturen, om den inte hittas, återgår den till dess överordnade kultur. För övrigt representerar egenskapen CultureInfo.Parent den överordnade kulturen. Detta innebär vanligtvis (men inte alltid) att den nationella beteckningen tas bort från ISO-koden. Till exempel är dialekten av spanska som talas i Mexiko "es-MX". Det överordnade är "es"—spanska som inte är specifikt för något land.
Anta att din webbplats får en begäran om en "Välkommen"-resurs med hjälp av kulturkodfr-CA. Lokaliseringssystemet söker efter följande resurser i ordning och väljer den första matchningen:
- Welcome.fr-CA.resx
- Welcome.fr.resx
- 
              Welcome.resx (om NeutralResourcesLanguageär "fr-CA")
Om du till exempel tar bort kulturdesignatorn ".fr" och har kulturen inställd på franska, läss standardresursfilen och strängar lokaliseras. Resurshanteraren anger en standard- eller återställningsresurs för när ingenting uppfyller den begärda kulturen. Om du bara vill returnera nyckeln när du saknar en resurs för den begärda kulturen får du inte ha någon standardresursfil.
Generera resursfiler med Visual Studio
Om du skapar en resursfil i Visual Studio utan kultur i filnamnet (till exempel Welcome.resx) skapar Visual Studio en C#-klass med en egenskap för varje sträng. Det är vanligtvis inte vad du vill ha med ASP.NET Core. Du har vanligtvis ingen .resx-standardresursfil (en .resx-fil utan kulturnamnet). Vi föreslår att du skapar .resx-filen med ett kulturnamn (till exempel Welcome.fr.resx). När du skapar en .resx-fil med ett kulturnamn genererar Inte Visual Studio klassfilen.
Lägga till andra kulturer
Varje språk- och kulturkombination (förutom standardspråket) kräver en unik resursfil. Du skapar resursfiler för olika kulturer och nationella inställningar genom att skapa nya resursfiler där ISO-språkkoderna ingår i filnamnet (till exempel en-us, fr-caoch en-gb). Dessa ISO-koder placeras mellan filnamnet och filtillägget .resx , som i Välkommen.es-MX.resx (spanska/Mexiko).
Implementera en strategi för att välja språk/kultur för varje begäran
Konfigurera lokalisering
Lokalisering konfigureras i Startup.ConfigureServices metoden:
services.AddLocalization(options => options.ResourcesPath = "Resources");
services.AddMvc()
    .AddViewLocalization(LanguageViewLocationExpanderFormat.Suffix)
    .AddDataAnnotationsLocalization();
- AddLocalizationlägger till lokaliseringstjänsterna i tjänstcontainern. Koden ovan anger även resurssökvägen till "Resurser".
- AddViewLocalizationlägger till stöd för lokaliserade vyfiler. I den här exempelvyn baseras lokaliseringen på vyfilsuffixet. Till exempel "fr" i- Index.fr.cshtmlfilen.
- AddDataAnnotationsLocalizationlägger till stöd för lokaliserade valideringsmeddelanden- DataAnnotationsvia- IStringLocalizerabstraktioner.
Mellanprogram för lokalisering
Den aktuella kulturen ställs in i lokaliseringsmellanprogrammet för en begäran. Mellanprogrammet för lokalisering är aktiverat i Startup.Configure -metoden. Lokaliseringens mellanprogramvara måste konfigureras före andra mellanprogram som kan kontrollera begärandekulturen (till exempel app.UseMvcWithDefaultRoute()). Mellanprogram för lokalisering måste visas efter routning av mellanprogram om du använder RouteDataRequestCultureProvider. Mer information om mellanprogramsordning finns i ASP.NET Core Middleware.
var supportedCultures = new[] { "en-US", "fr" };
var localizationOptions = new RequestLocalizationOptions().SetDefaultCulture(supportedCultures[0])
    .AddSupportedCultures(supportedCultures)
    .AddSupportedUICultures(supportedCultures);
app.UseRequestLocalization(localizationOptions);
Om du vill se kodkommentar översatta till andra språk än engelska kan du meddela oss i det här GitHub-diskussionsproblemet.
              UseRequestLocalization initierar ett RequestLocalizationOptions objekt. På varje begäran uppräknas listan över RequestCultureProvider i RequestLocalizationOptions, och den första providern som kan identifiera begärandekulturen används. Standardprovidrar kommer från RequestLocalizationOptions klassen:
- QueryStringRequestCultureProvider
- CookieRequestCultureProvider
- AcceptLanguageHeaderRequestCultureProvider
Standardlistan går från den mest specifika till den minst specifika. Senare i artikeln får vi se hur du kan ändra ordningen och till och med lägga till en anpassad kulturprovider. Om ingen av leverantörerna kan fastställa begärandekulturen används den DefaultRequestCulture .
QueryStringRequestCultureProvider
Vissa appar använder en frågesträng för att ange CultureInfo. För appar som använder cookie eller Accept-Language sidhuvudmetod är det användbart att lägga till en frågesträng i URL:en för felsökning och testning av kod. Som standardinställning är QueryStringRequestCultureProvider registrerad som den första lokaliseringsleverantören i RequestCultureProvider-listan. Du skickar frågesträngsparametrarna culture och ui-culture. I följande exempel ställs den specifika kulturen (språk och region) in till spanska/Mexiko.
http://localhost:5000/?culture=es-MX&ui-culture=es-MX
Om du bara skickar någon av de två (culture eller ui-culture) anger frågesträngsprovidern båda värdena med den som du skickade in. Om du till exempel bara anger kulturen anges både Culture och :UICulture
http://localhost:5000/?culture=es-MX
CookieRequestCultureProvider
Produktionsappar tillhandahåller ofta en mekanism för att ange kulturen med ASP.NET Core-kulturen cookie. Använd MakeCookieValue metoden för att skapa en cookie.
              CookieRequestCultureProvider
              DefaultCookieName Returnerar standardnamnet cookie som används för att spåra användarens önskade kulturinformation. Standardnamnet för cookie är .AspNetCore.Culture.
Formatet cookie är c=%LANGCODE%|uic=%LANGCODE%, var c är Culture och uic är UICulture, till exempel:
c=en-UK|uic=en-US
Om du bara anger en kulturinformation och en användargränssnittskultur används den angivna kulturen för både kulturinformation och användargränssnittskultur.
HTTP-huvudet för Accept-Language
Den Accept-Language rubriken kan anges i de flesta webbläsare och var ursprungligen avsedd att ange användarens språk. Den här inställningen anger vad webbläsaren har angetts för att skicka eller har ärvt från det underliggande operativsystemet. Det Accept-Language HTTP-huvudet från en webbläsarbegäran är inte ett ofelbart sätt att identifiera användarens föredragna språk (se Ange språkinställningar i en webbläsare). En produktionsapp bör innehålla ett sätt för en användare att anpassa sitt val av kultur.
Ange Accept-Language HTTP-huvud i IE
- Tryck på Internetalternativ från kugghjulsikonen. 
- Tryck på Språk.   
- Tryck på Ange språkinställningar. 
- Tryck på Lägg till ett språk. 
- Lägg till språket. 
- Tryck på språket och tryck sedan på Flytta upp. 
Använd en anpassad leverantör
Anta att du vill låta dina kunder lagra sitt språk och sin kultur i dina databaser. Du kan skriva en tjänst för att hitta dessa värden för användaren. Följande kod visar hur du lägger till en anpassad provider:
private const string enUSCulture = "en-US";
services.Configure<RequestLocalizationOptions>(options =>
{
    var supportedCultures = new[]
    {
        new CultureInfo(enUSCulture),
        new CultureInfo("fr")
    };
    options.DefaultRequestCulture = new RequestCulture(culture: enUSCulture, uiCulture: enUSCulture);
    options.SupportedCultures = supportedCultures;
    options.SupportedUICultures = supportedCultures;
    options.AddInitialRequestCultureProvider(new CustomRequestCultureProvider(async context =>
    {
        // My custom request culture logic
        return await Task.FromResult(new ProviderCultureResult("en"));
    }));
});
Använd RequestLocalizationOptions för att lägga till eller ta bort lokaliseringsprovidrar.
Ändringsbegäran för kulturleverantörers beställning
              RequestLocalizationOptions har tre standardleverantörer för begärandekultur: QueryStringRequestCultureProvider, CookieRequestCultureProvideroch AcceptLanguageHeaderRequestCultureProvider. Använd egenskapen [RequestLocalizationOptions.RequestCultureProviders]](xref:Microsoft.AspNetCore.Builder.RequestLocalizationOptions.RequestCultureProviders) för att ändra ordningen på dessa leverantörer enligt följande:
    app.UseRequestLocalization(options =>
    {
        var questStringCultureProvider = options.RequestCultureProviders[0];    
        options.RequestCultureProviders.RemoveAt(0);
        options.RequestCultureProviders.Insert(1, questStringCultureProvider);
    });
I föregående exempel är ordningen av QueryStringRequestCultureProvider och CookieRequestCultureProvider omvänt, så RequestLocalizationMiddleware letar efter kulturerna från kakor först och sedan frågesträngen.
Som tidigare nämnts lägger du till en anpassad provider via AddInitialRequestCultureProvider vilken anger ordningen till 0, så att den här providern har företräde framför de andra.
Ange kulturen programmatiskt
Det här projektet Localization.StarterWeb på GitHub innehåller ett användargränssnitt för att ange Culture. Med Views/Shared/_SelectLanguagePartial.cshtml filen kan du välja kulturen i listan över kulturer som stöds:
@using Microsoft.AspNetCore.Builder
@using Microsoft.AspNetCore.Http.Features
@using Microsoft.AspNetCore.Localization
@using Microsoft.AspNetCore.Mvc.Localization
@using Microsoft.Extensions.Options
@inject IViewLocalizer Localizer
@inject IOptions<RequestLocalizationOptions> LocOptions
@{
    var requestCulture = Context.Features.Get<IRequestCultureFeature>();
    var cultureItems = LocOptions.Value.SupportedUICultures
        .Select(c => new SelectListItem { Value = c.Name, Text = c.DisplayName })
        .ToList();
    var returnUrl = string.IsNullOrEmpty(Context.Request.Path) ? "~/" : $"~{Context.Request.Path.Value}";
}
<div title="@Localizer["Request culture provider:"] @requestCulture?.Provider?.GetType().Name">
    <form id="selectLanguage" asp-controller="Home" 
          asp-action="SetLanguage" asp-route-returnUrl="@returnUrl" 
          method="post" class="form-horizontal" role="form">
        <label asp-for="@requestCulture.RequestCulture.UICulture.Name">@Localizer["Language:"]</label> <select name="culture"
          onchange="this.form.submit();"
          asp-for="@requestCulture.RequestCulture.UICulture.Name" asp-items="cultureItems">
        </select>
    </form>
</div>
Filen Views/Shared/_SelectLanguagePartial.cshtml läggs till i footer avsnittet i layoutfilen så att den blir tillgänglig för alla vyer:
<div class="container body-content" style="margin-top:60px">
    @RenderBody()
    <hr>
    <footer>
        <div class="row">
            <div class="col-md-6">
                <p>© @System.DateTime.Now.Year - Localization</p>
            </div>
            <div class="col-md-6 text-right">
                @await Html.PartialAsync("_SelectLanguagePartial")
            </div>
        </div>
    </footer>
</div>
Metoden SetLanguage anger kulturen cookie.
[HttpPost]
public IActionResult SetLanguage(string culture, string returnUrl)
{
    Response.Cookies.Append(
        CookieRequestCultureProvider.DefaultCookieName,
        CookieRequestCultureProvider.MakeCookieValue(new RequestCulture(culture)),
        new CookieOptions { Expires = DateTimeOffset.UtcNow.AddYears(1) }
    );
    return LocalRedirect(returnUrl);
}
Du kan inte koppla in _SelectLanguagePartial.cshtml till exempelkoden för det här projektet. Projektet Localization.StarterWeb på GitHub har kod för att flöda RequestLocalizationOptions till en Razor del via containern Dependency Injection .
Modellbindning av routningsdata och frågesträngar
Se Globaliseringsbeteende för modellbindning av routningsdata och frågesträngar.
Villkor för globalisering och lokalisering
Processen för att lokalisera din app kräver också en grundläggande förståelse av relevanta teckenuppsättningar som ofta används i modern programvaruutveckling och en förståelse för de problem som är associerade med dem. Även om alla datorer lagrar text som siffror (koder) lagrar olika system samma text med olika tal. Lokaliseringsprocessen syftar på översättning av appens användargränssnitt (UI) för en specifik kultur/nationella inställningar.
Localizability är en mellanliggande process för att verifiera att en globaliserad app är redo för lokalisering.
              RFC 4646-formatet för kulturnamnet är <languagecode2>-<country/regioncode2>, där <languagecode2> är språkkoden och <country/regioncode2> är subkulturkoden. Till exempel es-CL för spanska (Chile), en-US för engelska (USA) och en-AU för engelska (Australien). 
              RFC 4646 är en kombination av en ISO 639-kod med två små bokstäver som är associerad med ett språk och en ISO 3166-kod med två stora bokstäver som är associerad med ett land eller en region. Mer information finns i System.Globalization.CultureInfo.
Internationalisering förkortas ofta till "I18N". Förkortningen tar de första och sista bokstäverna och antalet bokstäver mellan dem, så 18 står för antalet bokstäver mellan det första "I" och det sista "N". Detsamma gäller globalisering (G11N) och lokalisering (L10N).
Terms:
- Globalisering (G11N): Processen för att skapa en app stöder olika språk och regioner.
- Lokalisering (L10N): Processen för att anpassa en app för ett visst språk och en viss region.
- Internationalisering (I18N): Beskriver både globalisering och lokalisering.
- Kultur: Det är ett språk och, om du vill, en region.
- Neutral kultur: En kultur som har ett angivet språk, men inte en region. (till exempel "en", "es")
- Specifik kultur: En kultur som har ett angivet språk och en viss region. (till exempel "en-US", "en-GB", "es-CL")
- Moderkultur: Den neutrala kultur som innehåller en specifik kultur. (till exempel är "en" den överordnade kulturen "en-US" och "en-GB")
- Nationella inställningar: Ett språk är samma som en kultur.
Note
Du kanske inte kan ange decimaltecken i decimalfält. Om du vill stödja jQuery-validering för språkvarianter som inte är engelska och som använder kommatecken (",") för decimaltecken och datumformat som inte US-English måste du vidta åtgärder för att globalisera din app. Se den här GitHub-kommentaren 4076 för instruktioner om hur du lägger till decimal kommatecken.
Note
Innan ASP.NET Core 3.0-webbappar skriver du en logg av typen LogLevel.Warning per begäran om den begärda kulturen inte stöds. Att skriva en LogLevel.Warning per begäran kan skapa stora loggfiler med redundant information. Det här beteendet har ändrats i ASP.NET Core 3.0. Skriver RequestLocalizationMiddleware en logg av typen LogLevel.Debug, vilket minskar storleken på produktionsloggarna.
Ytterligare resurser
ASP.NET Core