У меня есть ощущение, что у этого вопроса нет прямого ответа. Для форматирования и того, что вы не должны всегда использовать Culture и UICulture, например, «en-GB» для британского английского и «en-US» для американского английского (да, есть разница). Все .Net построено вокруг него, и таким образом вы можете использовать локальное форматирование, не думая об этом.
Вы должны также проверить пространство имен System.Globalization для более подробной информации: http://msdn.microsoft.com/en-us/library/system.globalization%28v=vs.110%29.aspx
Что касается были культура должна исходить от, то, по крайней мере, в нашей компании политика всегда без исключения из строки запроса. Причиной этого является то, что если вы используете локализацию IP, например, если испанский пользователь смотрит на испанский сайт в Японии, а затем переключается на японскую версию, то не совсем неправильно, но может раздражать, если вы сказали клиент, что это прямая испанская ссылка или что-то в этом роде. Тем не менее, если культура не определена в строке запроса, то использование IP для угадывания с языком, который пользователь хотел бы иметь, не будет плохой идеей, но на самом деле зависит от потребностей ваших клиентов.
Что касается того, чтобы получить переводы, то это действительно зависит, и ресурсы, и БД имеют свои взлеты и падения. Таким образом, основные точки для БД - это то, что их легко распределить между приложениями, и если вам нужно обновить фразу по любой причине, то вы можете обновить их все через одну запись в БД, но это может быть и ошибкой, потому что некоторые фразы имеют двойное значение и могут быть переведены совершенно по-другому на других языках, хотя одно и то же предложение используется на английском языке. Другая большая проблема с БД заключается в том, что до некоторой степени (но это зависит от реализации) вы теряете интеллект в VS для фраз.
Ресурсы, конечно, имеют соответствующий интеллект, но они довольно статичны для используемого вами веб-приложения, вы не можете делиться ресурсами между приложениями ... ну не совсем верно, но более или менее вы не можете. Хотя этот статический характер также является плюсом, потому что все ресурсы содержатся в приложении, и вы знаете, что никакой внешний эффект не может повлиять на него.
В действительности это действительно зависит от проекта в руке. вам просто нужно сделать свои собственные плюсы и минусы и решить для себя ... извините. Но если это вообще поможет, я могу рассказать вам, как обстоят дела в моей компании. Мы делаем несколько приложений, которые используют одни и те же фразы в разных веб-приложениях. Раньше у нас это было в БД, но произошло то, что переводы продолжали идти массивом, то есть клиент попросил улучшить перевод на испанском языке для одного приложения, но это не имело никакого смысла, что когда-либо было на других. Это произошло больше, чем вы могли подумать. Затем мы перешли к ресурсам, но произошло то, что когда обновление одного приложения было обновлено, никто не помнил, чтобы обновлять другие приложения, и на самом деле случилось, что 3 разных приложения перевели один и тот же термин тремя разными способами. В конце концов мы решили вернуться к БД, потому что способность менять все переводы сразу означала для нас больше, а затем тот факт, что внешнее влияние не может повлиять на нее.
В целом есть и другие плюсы и минусы, но все, что довольно не имеет значения по сравнению с вышеуказанным. Вам действительно нужно спросить, как вы используете переводы.Что касается общего редактирования (исключая вышеупомянутую точку), то подход aider работает так же хорошо, вы можете так же легко изменять и редактировать или расширять переводы с помощью обоих подходов.
Сказано, что если DB и вызовы БД разработаны плохо, то добавление новых языков может быть проще с ресурсами, просто скопируйте файл ресурсов, добавьте расширение культуры к имени и добавьте перевод на ресурс, и вы выполняются, но опять же, полностью вплоть до проектирования БД, так что это нужно иметь в виду при разработке БД и ничего не говорит о проведении переводов в БД.
В целом я бы сказал, что ресурсы проще в использовании и очень удобны в обслуживании и расширении (и они уже встроены в .NET), хотя у DB есть явное преимущество, если вам нужно делиться переводами. Поэтому, если бы я сказал, что рекомендую использовать ресурсы, но у БД есть место, и это действительно зависит от проекта.