Sly32

Рейтинг
367
Регистрация
29.03.2012
webinfo #:

Да там 100500 способов реализации. Выбор конкретного способа зависит от конкретного проекта. И да, в файлах тоже хранят, но нет так, как у тебя, а переводы фраз.

Я не требую за меня решать. Знаю что вариантов множество. Мне интересно, как бы ты решал эту проблему. Не привязывайся к проекту, исходи из задачи. Для сайта - окей, приведи как бы ты делал многоязычное меню для сайта.

WebStorm #:
тогда я приношу извинения, реализация нормальная

Спасибо за интересную дискуссию

estic #:
В итоге получается ваш вариант 1.

все верно, и свои консерны к этому способу я уже высказывал, но да - он самый быстрый

WebStorm #:
я не знаком с pyton, но Fastapi кэширует в итоге этот  "малюсенький объект" в каком виде? снова в json?, если да, то всё равно он его будет снова и снова парсить

Нет, я думал ты знаком с питон. Приведенный код один раз обращается к файлу, получает нужные данные по ключу. Потом json  конвертируется в питоновский обьект типа "словарь"(dict), если не ошибаюсь, это аналог пхпэшного array, и уже в байткоде путешествует дальше. То есть ничего не разрастется. добавлю в json строку иеню - скомпилируется и буде использована. При этом мне не надо лезть руками в код-файлы, все можно реализовать через пользовательский интерфейс

funnyworld :
С точки зрения безопасности, лучше ли делать авторизацию на вашем сайте только через Google и Facebook? Какие подводные камни и проблемы?

Гораздо надежнее чем авторизация через логин/пароль. Удобно для пользователей. Всегда стараюсь использовать. Не слышал историй, чтоюы получили доступ  несанкционированный  таким способом Там токенизация, ее поломать крайне сложно. А если еще и вход черех двухфакторную - можно спать спокойно.

webinfo #:

Смешно... Если почитать тему, кто здесь что пишет. Ну ладно, продолжай блистать.

Слушай, если у тебя есть возражения по техчасти, реализации - добро пожаловать, с удовольствием выслушаю. Мне на самом деле эта дискуссия очень помогает - пытаясь сформулировать ответы, я уже оптимизировал свой код  неплохо. Давай не будем переходить на стиль Арбнета. Если аргументируешь плюсы за базу данных, покажешь как бы ты хранил это в БД, как получалбы - буду очень благодарен, может я что-то упускаю и твой вариант окажется верным?

WebStorm #:

и на вашу текущую реализацию

1 - во-первых с портянкой со всеми языками в одном файле, зачем если нужен только один язык, подгружать сразу все переводы?

Спасибо за комментарии, не думал что python код так сложен для понимания, поясняю. Все данные никогда не выгребаются. Вот есть условный роутер, обрабатывающий запросы типа

site.com/{lang}/users/profile   когда пользователь в меню выбирает язык ru происходит переадресайия на  урл 

site.com/ru/users/profile

Соотвтетсвенно роутер идет в этот мой большой JSON:

{
    "en": {
        "subjects": {
            "subjects": {
                "chemistry": "chemistry",
                "math": "mathematics"
            }
        },
        "mentors": "mentors",
        "scheduler": "scheduler",
        "news": "news",
        "adverts": "adverts"
    },
    "ru": {
        "subjects": {
            "предметы": {
                "chemistry": "химия",
                "math": "математика"
            }
        },
        "mentors": "преподаватели",
        "scheduler": "расписание",
        "news": "новости",
        "adverts": "обьявления"
    }
}

И по ключу "ru" выгребает только  данные для русского интерфейса:

"ru": {
        "subjects": {
            "предметы": {
                "chemistry": "химия",
                "math": "математика"
            }
        },
        "mentors": "преподаватели",
        "scheduler": "расписание",
        "news": "новости",
        "adverts": "обьявления"
    }

Fastapi умеет кэшировать  данные и пока пользователь не сменит язык - ему будет подгружаться  интерфейс из "ru" интерфейса. 
То есть в шаблонизатор приходит малюсенький обьект только с тем что нужно.

WebStorm #:
тогда лучше всего прикрутить компиляцию джейсона в py

так и есть:

def get_language(lang: str = "en") -> dict:
    file_name = "lang_settings.json"
    file_path = "".join((os.getcwd(), "/src/settings/", file_name))
    with open(file_path, "r") as f:
        data = json.load(f)
        lang = data.get(lang)
        if not lang:
            return data.get("en")
        return lang
WebStorm #:

ещё раз повторяю, я не агитировал за хранение текстов интерфейса в базе, а обратил внимание на глупый вопрос "как мне потом обрабатывать это? "

Ну, выше, я вроде уточнил свой вопрос. В дискуссии принято исходить от высшего уровня к нижнему. Архитектура приложения. Сначала интерфейс, потом детали реализации. в данном случае интерфейс(хранение  в файлах( пусть даже и в коде) предпочтительнее  хранения в базе. Это слишком дорого. Да, в коде - самое быстрое, но чревато проблемами, описанными выше. Ну и хранение в разных файлах противоречит как SOLID так и DRY - не повторяйся. У меня один роутер  будет обрабатывать  все языки, соответственно если мне нужно поменять что-то, мне нужно поменять что-то в обработчике  и в языковом файле, а не в 6 разных файлов для 6-ти языков.

webinfo #:
Вот и стоило бы грамотно сформулировать заголовок темы и хотя бы стартпост

пока что срач устраиваешь ты и Арбнет, остальные хоть как-то  аргументируют свою позицию.

WebStorm #:
где я агитировл за хранение текстов интерфейса в базе? я просто ответил на твой вопрос "а что я буду делать со строками из базы"

Это не ответ.  Или ты не прочитал всю дискуссию.  Гениальный Арбнет сказал что все запросто можно хранить в одной талице, я усомнился, попросил доказать. Ни от тебя ни от него ответа я не увидел - как?

WebStorm #:
я не агитировал, а обратил внимание на безграмотность

безграмотность  - это не понимать какой инструмент и для чего,  пытаться давать советы, не зная темы.  В итоге отказ от хранения языковых файлов в базе оказывается правильным даже с твоей точки зрения. Люблю критику, когда она на чем -то основывается. 

Всего: 7118