Согласен. В данном случае, когда генератор делает все за тебя любой из описанных методов является рабочим. Но, увы, не всегда верным.
Я же руководствуюсь принципом 7 раз отмерь 1 отрежь. Хочу добиться правильного соотношения понятность/эффективность/универсальность.
И согласно моему выбору, в котором, надеюсь, мне помогут ваши комментарии я разработаю соответствующий генератор для своего фреймворка. И соответственно убрать рутину из разработки, хотя всю рутину не уберешь никогда, наверное :).
Простите за слово «корявость», это было выражением двух последних абзацев в вашем комментарии. :)
Ну а если нам необходима языковая расширяемость? Приходится при добавлении нового языка дублировать все поля и дописывать им новые префиксы. И чем больше у нас языков, тем больше у нас столбцов в таблице и тем корявей это начинает выглядеть.
И задача стоит конкретно переводить не интерфейс а контент.
Представим случай интернациональным интернет-магазином, где есть, ну очень много товаров. И у нас наивная цель сделать возможным перевод на любой язык с любого языка.
Тогда имеет право на жизнь 3-й вариант. И то, непонятно, как реализовать правильный интерфейс перевода.
Ну второй вариант правильней связывать по странице оригинала текста и админить так же. Это будет более универсальным решением, когда речь идет о создании любой структуры. Хотя и ваш вариант тоже является выходом из положения.
Ну а для своего фреймворка, я считаю нужным вшить возможность интернационализации. Думаю только над выбором варианта.
Интересно есть ли другие механизмы.
Я понимаю о чем вы, я изучал этот инструмент, но интересует именно не локализация текста шаблона (имеется в виду всяческие текстовые переменные такие, как сообщения об ошибках) это уже реализовано.
Интересует комплексный подход к интернационализации, когда у нас есть именно контент, который нужно перевести и который хранится в базе.
«Пластинка воспроизводит музыку, на компакт-диске же музыка преобразована в нули и единицы»
Но ведь теперешние методы записи подразумевают предварительную оцифровку, а при переносе на винил, логично что мы слушаем те же цифры, только с «теплотой», которая, как я считаю, действительно присутствует.
Я же руководствуюсь принципом 7 раз отмерь 1 отрежь. Хочу добиться правильного соотношения понятность/эффективность/универсальность.
И согласно моему выбору, в котором, надеюсь, мне помогут ваши комментарии я разработаю соответствующий генератор для своего фреймворка. И соответственно убрать рутину из разработки, хотя всю рутину не уберешь никогда, наверное :).
Простите за слово «корявость», это было выражением двух последних абзацев в вашем комментарии. :)
Ну а если нам необходима языковая расширяемость? Приходится при добавлении нового языка дублировать все поля и дописывать им новые префиксы. И чем больше у нас языков, тем больше у нас столбцов в таблице и тем корявей это начинает выглядеть.
И задача стоит конкретно переводить не интерфейс а контент.
Тогда имеет право на жизнь 3-й вариант. И то, непонятно, как реализовать правильный интерфейс перевода.
У вас есть какие-нибудь примеры реализации?
Ну а для своего фреймворка, я считаю нужным вшить возможность интернационализации. Думаю только над выбором варианта.
Интересно есть ли другие механизмы.
Интересует комплексный подход к интернационализации, когда у нас есть именно контент, который нужно перевести и который хранится в базе.
Нет чтоб освятить карму, так они туда это…
Но ведь теперешние методы записи подразумевают предварительную оцифровку, а при переносе на винил, логично что мы слушаем те же цифры, только с «теплотой», которая, как я считаю, действительно присутствует.
Судя с обзора записи винилов it.youtube.com/watch?v=XvCLmPubXps