Переводы не работают удаленно только в локальной среде
В моем браузере, который я запускаю из своей локальной среды, строки переводятся так, как предполагалось. Когда я загружаю в Azure, он все еще работает. Однако, когда я переключаюсь на Edge (который я никогда не использую ни для чего, кроме загрузки FireFox), строки больше не переводятся. Я проверил с внешними пользователями в широком диапазоне браузеров, и, похоже, проблема не зависит от платформы.
У меня есть все мои переводы в глобальном файле, размещенном в корневом каталоге, и у меня есть фиктивный файл, поэтому я могу внедрить его в представления и контроллеры, как это предлагается в документах. Почему-то кажется, что файл RESX не найден, поэтому я поместил его в Всегда загружать. Но никаких изменений в поведении.
Я не уверен, как его диагностировать дальше, или файл RESX скомпилирован в DLL или загружен прямо на сервер и прочитан на лету. Можно ли как-то проверить, что файл находится «там наверху»?
Мой конфиг такой.
public void ConfigureServices(IServiceCollection services)
{
...
services.AddLocalization(a => a.ResourcesPath = "");
services.Configure<RequestLocalizationOptions>(a =>
{
CultureInfo[] supportedCultures = {
new CultureInfo("sv-SE"),
new CultureInfo("se")
};
a.DefaultRequestCulture = new RequestCulture("se");
a.SupportedCultures = supportedCultures;
a.SupportedUICultures = supportedCultures;
});
...
services.AddMvc()
.AddViewLocalization(LanguageViewLocationExpanderFormat.Suffix)
.SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
...
app.UseRequestLocalization();
...
app.UseMvcWithDefaultRoute();
}
редактировать
Я заметил, что это работает в Chrome, когда у меня есть эти строки.
RequestLocalizationOptions options = app.ApplicationServices
.GetService<IOptions<RequestLocalizationOptions>>().Value;
app.UseRequestLocalization(options);
Он перестает работать, когда они у меня есть.
//RequestLocalizationOptions options = app.ApplicationServices
// .GetService<IOptions<RequestLocalizationOptions>>().Value;
app.UseRequestLocalization();
В IE это не работает в любом случае.
@ Александр, я вижу, я не совсем понял этот вопрос. Строки не переводятся ни в одном браузере, если этот браузер не использовался "с тех пор, как раньше". Не знаю, как долго, но обычно я запускаю свои программы в Cr и FF, и на моем компьютере все работает. Однако те же браузеры на другом компьютере не работают. И что еще более странно, даже локальный запуск в IE и, например, не работает. Но просто чтобы исключить возможность того, что это что-то с файлами cookie - как мне указать файл cookie в соответствии с вашим предложением?
Хорошо, если с файлом cookie что-то не так, вы все равно должны были увидеть перевод для культуры по умолчанию (se в вашем случае). Странно, что в одном браузере работает, а в другом нет, потому что браузер никак не влияет на процесс локализации (ну, он только задает культуру запроса, и все). И если раньше это работало, а сейчас не работает, значит, вы что-то меняли в проекте, в частности, в файлах локализации. А что такое фиктивный файл? Как называется ваш файл с локализациями?
вы изменили этот код запуска? Конечно, вы сказали, что это работает, но я ожидал, что служба RequestLocalizationOptions будет передана в UseRequestLocalization. Например, var locOptions = app.ApplicationServices.GetService<IOptions<RequestLocalizationOptions>>(); app.UseRequestLocalization(locOptions.Value);
@Александр Отличные очки. Работал и работает все еще в Cr и FF (как локально, так и удаленно). Это не работает в Eg и IE (loco и remo). В настоящее время я прошу людей установить браузеры и проверить свои системы. Похоже, браузеры, использовавшиеся изначально при разработке, что-то накосячили... Что касается пустышки - это просто пустой класс, который я использую при инжекте IStringLocalization<Lingo>. Мой файл RESX называется Ling.se.resx (я также создал Controller.Lingo.se.resx в чистом виде). Я хочу пока сохранить весь перевод в одном файле по практическим соображениям. Помощь?
@eVolve Я попробую это прямо сейчас. Я все еще немного запутался в локализации а-ля .NET Core, так что, возможно, я сделал что-то довольно глупое. Однако я заметил предупреждение о том, что промежуточное ПО для локализации запросов выдало браузерам AcceptLanguageHeaderRequestCultureProvider вернул следующие неподдерживаемые языки и региональные параметры «en-US, en, sv» в все.
@Alexander Пожалуйста, смотрите правку в вопросе. Я заметил, что мог бы подразумевает источник ошибки, если кто-то достаточно мудр.
В вопросе все еще не хватает деталей для диагностики проблемы. Сначала определите, с каким методом локализации вы хотите, чтобы ваше приложение работало. Основываясь на том, что вы сказали, я подозреваю, что ваше приложение использует AcceptLanguageHeaderRequestCultureProvider, и чтобы это работало в IE/Edge, вы должны установить HTTP-заголовок Accept-Language. @Alexander упомянул о локализации файлов cookie и является еще одним методом, позволяющим установить культуру. Эта ссылка описывает их, а также показывает локализацию файлов cookie andrewlock.net/….
Ваше редактирование сделало режим странным, потому что вам не нужно ничего передавать в ` app.UseRequestLocalization()`, если вы это сделали services.Configure<RequestLocalizationOptions>. DI сделает все за вас.
@Александр Вы правы. Это действительно странно, потому что он не должен вести себя таким образом. Я подозреваю, что по своему невежеству описываю это вводящим в заблуждение образом (утверждая истинные факты, но, возможно, неправильно, возможно, опуская что-то существенное). Дай мне поковыряться и вернуться. На данный момент я заставил его «работать», но пропустил app.UseRequestLocalization() (что заставляет его использовать RESX по умолчанию, то есть Lingo.resx во всех браузерах). Это будет продолжаться до тех пор, пока я буду использовать только шведский язык, что вряд ли является удовлетворительной глобализацией, хе-хе. Как теперь кажется, использование app.UseXxx не указывает на правильный файл.
Ответы 1
Пара слов о настройке культуры. Я думаю, вы хотели указать только шведскую локаль, поэтому у вас есть эта строка кода
CultureInfo[] supportedCultures = {
new CultureInfo("sv-SE"),
new CultureInfo("se")
};
Оказывается, sv-SE — это определенно культура Шведский, но se — это культура северные саамы. Если вы намерены использовать только культуру Шведский, вам нужно установить sv вместо se
CultureInfo[] supportedCultures = {
new CultureInfo("sv-SE"),
new CultureInfo("sv")
};
a.DefaultRequestCulture = new RequestCulture("sv");
Вернемся к основной проблеме. По умолчанию существует 3 способа установить культуру запроса: через строку запроса, файлы cookie или заголовок Accept-Language. Похоже, вы не указали культуру в файлах cookie запроса или строке запроса, но ваш браузер отправляет заголовок Accept-Language, из которого ASP.NET Core считывает культуру запроса. Если браузер отправляет en-US, en и sv культуры, ни одна из них не соответствует supportedCultures (то есть sv-SE и se), фреймворк возвращается к DefaultRequestCulture (то есть se) и считывает ресурсы из Lingo.se.resx, и все в порядке. Но похоже, что Edge (в любом другом браузере, но на другом компьютере) отправил другой набор культур в заголовке Accept-Language, который включал sv-SE, содержащийся в supportedCultures. Таким образом, читатель ресурсов искал файл Lingo.sv-se.resx или Lingo.sv.resx, но безуспешно, поэтому перевод не был предоставлен.
Если мое предположение верно, изменение se на sv в вашем коде и переименование Lingo.se.resx на Lingo.sv.resx решит проблему.
Используете ли вы локализацию файлов cookie? Возможно (но я не уверен), что что-то не так с куками в Edge. Поэтому попробуйте указать культуру через строку запроса и посмотрите, работает ли она в Edge.