Сравнение языковых файлов Opencart

- Posted in Uncategorized by

При поиске различий в языковых файлах Opencart огромную неприятность доставляет то, что утилиты наподобие DIFF оказываются почти бесполезны. Они сравнивают файлы построчно, а поскольку приходится сравнивать английский файл с русским, то 99% строк разные из-за перевода. И найти в этих условиях новые и удаленные переменные в файлах локализации оказывается очень сложно и муторно. Графические аналоги подобных программ тоже не очень-то помогают, даже если способны подсвечивать разницу внутри одной строки: в глазах рябит, строки длинные, и после проверки пары каталогов эта рутинная и фактически ручная визуальная проверка просто выматывает.

Но у линукс-пользователей есть способ существенно облегчить себе задачу поиска различий, сравнивая лишь часть строк из двух файлов!

В файлах локализации неизменной для русской и английской версии остается левая часть строк до знака '='. Их и будем сравнивать. На помощь утилите diff приходит утилита cut:

#!/bin/bash
diff -b <(cut -d'=' -f1 -s $1) <(cut -d'=' -f1 -s $2)

Указав этой утилитке имена двух файлов, получим краткий список отсутствующих и появившихся языковых переменных. Это то, чего мне долго не хватало!

Спасительная команда cut -d'=' -f1 -s setting.php выводит только первую часть строки (-f1), разделенной знаком '='. А diff сравнивает две этих "первых колонки" из обеих файлов, оставляя нам только разницу.

Про Quickcheckout 151x и новые версии Opencart

- Posted in Uncategorized by

Я всё никак не найду времени написать статью о том, почему QC не развивается и не поддерживаются новые версии Опенкарт. Заготовки (в ответах людям) периодически появляются, но времени сесть и оформить это, чтобы объяснить сразу всем и сразу - не находится.

Там такая ситуация.

  1. Начиная с 1.5.2 началась бурная перестройка в этой части Опенкарт - что-то связанное с налогами, плюс прочие изменения. Это означает, что модуль надо переделывать тщательно и полностью. Тонкостей налогообложения других стран не знаю, поэтому надо все изменения переносить, заново укорачивать и проверять: проблема в том, что когда я его делал, не нашёл другого способа, кроме как продублировать функционал оформления заказа, и его уже модифицировать. Способа использовать код OC, а не его копию, я не нашёл.
  2. Основной идеей Quickcheckout (QC) был полный отказ от всей адресно-географической информации. А с ней как раз расчет налогов и связан. Представьте: берём стандартный процесс и отрезаем от него половину. Вот это и есть QC. В итоге меня позже уговорили добавить к этому огрызку способы оплаты. Но ограничение-то никуда не делось - возвращать поддержку адресов и гео-зон означает возврат этого всего и в интерфейс, и во внутренности. Это, опять же, полная переделка того, что было.

Это всё не так просто, как может казаться на поверхности. По сути, нужен совершенно другой модуль: чтобы и все способы оплаты могли нормально работать, и совместимость с новыми версиями была. И в том, и в другом случае надо полностью модуль переделывать и на других принципах его строить. То есть переписать вообще всё и с нуля. И делать вместо обрезанной "половинки" (Quickcheckout) полноценный модуль-одностраничник (всё то же самое, что стандартные 6 шагов гармошкой, но на одной странице). То есть совершенно другая идея. Не просто "выбросить адреса", а "сделать стандартное, но очень коротко".

В тот момент (когда появились 1.5.2, 1.5.3) я был сильно занят и долго решал, в каком направлении надо развивать модуль и получится ли. Там архитектурных проблем хватает, поэтому продолжать по-старому было нереально (к тому времени уже не было никого, кто не хотел бы способы оплаты, и вот из-за них как раз нереально).

Потом уже появились альтернативы - и по той же цене, и даже бесплатные варианты. Сейчас, при наличии полноценных альтернатив и активной поддержке новых версий (simpleopencart.com например) писать ещё один такой же модуль-одностраничник и заниматься его поддержкой мне кажется странным - можно просто пользоваться готовым (Simple) для новых версий Опенкарт.

Поэтому если переделывать QC - получится полный аналог Simple, как ни крути. Потому что в старом виде (с обрезанной поддержкой адресной части) его развивать нет смысла (слишком много проблем возникает). И по цене они окажутся одинаковыми, и по внешнему виду, и по функционалу скорей всего (с минимальными отличиями).

А если так, то возникает вопрос - зачем? Если уже есть готовое решение.