[strings] Improve roads classification, add references #1779

pastk · 2022-01-04T15:09:29Z

pastk commented

2022-01-04 15:09:29 +00:00

Added references support for translation files in strings_utils.py

By default translations duplicated in a referenced definition are removed.
--keep-resolved-references option allows to keep/restore them if necessary.

See #1767. Added references support for translation files in `strings_utils.py` By default translations duplicated in a referenced definition are removed. `--keep-resolved-references` option allows to keep/restore them if necessary.

biodranik (Migrated from github.com) reviewed 2022-01-04 20:38:36 +00:00

data/strings/types_strings.txt

					
				@ -7545,3 +7533,2 @@

				    de = Reitweg

				    fr = Chemin pour cavalier

				    ref = type.highway.bridleway

				    ja = 馬道(トンネル)

biodranik (Migrated from github.com) commented

2022-01-04 20:38:35 +00:00

Может проще и надёжнее поправить код, чтобы он брал перевод от базового типа, вместо этих усложнений? @vng а сейчас перевод не берётся у базового?

biodranik (Migrated from github.com) reviewed 2022-01-04 20:40:10 +00:00

data/strings/types_strings.txt

					
				@ -7545,3 +7533,2 @@

				    de = Reitweg

				    fr = Chemin pour cavalier

				    ref = type.highway.bridleway

				    ja = 馬道(トンネル)

biodranik (Migrated from github.com) commented

2022-01-04 20:40:10 +00:00

Более того, переводы с базовых типов будут автоматом работать, если мы решим дальше добавлять подтипы (приватные парковки и бассейны, и пр.).

pastk reviewed 2022-01-04 21:16:18 +00:00

data/strings/types_strings.txt

					
				@ -7545,3 +7533,2 @@

				    de = Reitweg

				    fr = Chemin pour cavalier

				    ref = type.highway.bridleway

				    ja = 馬道(トンネル)

pastk commented

2022-01-04 21:16:18 +00:00

Я плохо представляю, что является "базовым типом" и где находится соответствующий код.
Например, highway.bus_stop и highway.footway.bridge - базовый тип будет у них разный highway и highway.footway соответственно?
А historic.memorial.plaque и historic.memorial.statue, например - тут возможность разного перевода очень даже подходит.

Я плохо представляю, что является "базовым типом" и где находится соответствующий код. Например, `highway.bus_stop` и `highway.footway.bridge` - базовый тип будет у них разный `highway` и `highway.footway` соответственно? А `historic.memorial.plaque` и `historic.memorial.statue`, например - тут возможность разного перевода очень даже подходит.

pastk reviewed 2022-01-04 21:21:34 +00:00

data/strings/types_strings.txt

					
				@ -7545,3 +7533,2 @@

				    de = Reitweg

				    fr = Chemin pour cavalier

				    ref = type.highway.bridleway

				    ja = 馬道(トンネル)

pastk commented

2022-01-04 21:21:34 +00:00

В любом случае эти ref'ы будет очень легко убрать при надобности и вернуть всё "как было". Пока же они дают возможность как делать точные переводы "полного типа", так и брать с базового. Причём можно брать с базового, только если нет перевода для "полного".

biodranik (Migrated from github.com) reviewed 2022-01-05 08:18:16 +00:00

data/strings/types_strings.txt

					
				@ -7545,3 +7533,2 @@

				    de = Reitweg

				    fr = Chemin pour cavalier

				    ref = type.highway.bridleway

				    ja = 馬道(トンネル)

biodranik (Migrated from github.com) commented

2022-01-05 08:18:16 +00:00

@vng очень хорошо разбирается. Должно работать так: выбирается базовый тип из классификатора, подходящий по смыслу (highway.footway) и переводится. Понятно, что highway.bus_stop должен быть с другим переводом, это другой тип. У нас обычно базовые типы имеют 2 уровня вложенности, и легко различимы на глаз. Очень не хочется тратить время на (по сути не нужный) ref, и потом его и откатывать ещё.

pastk reviewed 2022-01-05 08:55:47 +00:00

data/strings/types_strings.txt

					
				@ -7545,3 +7533,2 @@

				    de = Reitweg

				    fr = Chemin pour cavalier

				    ref = type.highway.bridleway

				    ja = 馬道(トンネル)

pastk commented

2022-01-05 08:55:47 +00:00

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

возможность перекрыть (override) дефолтный перевод для любого типа, например, для базовых типов highway.footway и historic.memorial иметь возможность перевести highway.footway.mountain_hiking и historic.memorial.statue иначе
в types_strings.txt должны присутствовать все типы, даже если все их переводы на данный момент взяты из базовых типов - иначе переводчики просто не будут знать, что есть возможность сделать точный перевод полного типа (и что он вообще существует)
в случае вроде highway.bus_stop вообще лучше не дефолтить на highway - лучше уж показать английское "Bus Stop", чем русское "Дорога", взятое из highway (в случае, если нет русского перевода для highway.bus_stop) - то же самое для других "широких" базовых типов, например nature и landuse; а вот разнообразные office.*, shop.* вполне можно дефолтить в базовые office и shop

Вообще да, пожалуй лучше, чтобы данная функциональность была в основном коде, а не во вспомогательном инструменте. Только хотелось бы, чтобы имеющаяся гибкость была сохранена. На мой взгляд важны следующие моменты: - возможность перекрыть (override) дефолтный перевод для любого типа, например, для базовых типов `highway.footway` и `historic.memorial` иметь возможность перевести `highway.footway.mountain_hiking` и `historic.memorial.statue` иначе - в `types_strings.txt` должны присутствовать все типы, даже если все их переводы на данный момент взяты из базовых типов - иначе переводчики просто не будут знать, что есть возможность сделать точный перевод полного типа (и что он вообще существует) - в случае вроде `highway.bus_stop` вообще лучше не дефолтить на `highway` - лучше уж показать английское "Bus Stop", чем русское "Дорога", взятое из `highway` (в случае, если нет русского перевода для `highway.bus_stop`) - то же самое для других "широких" базовых типов, например `nature` и `landuse`; а вот разнообразные `office.*`, `shop.*` вполне можно дефолтить в базовые `office` и `shop`

biodranik (Migrated from github.com) reviewed 2022-01-05 09:45:45 +00:00

data/strings/types_strings.txt

					
				@ -7545,3 +7533,2 @@

				    de = Reitweg

				    fr = Chemin pour cavalier

				    ref = type.highway.bridleway

				    ja = 馬道(トンネル)

biodranik (Migrated from github.com) commented

2022-01-05 09:45:45 +00:00

Разумно. Надо понимать, что многие наши типы, особенно highway.footway.bridge, это костыли для меньшего размера данных и более быстрой их обработки. По-хорошему, это были бы highway.footway с доп.признаками. И так для остальных примеров тоже. Но имеем что имеем, поэтому надо двигаться сюда:

Все отличающиеся по смыслу подтипы должны иметь хотя бы базовый английский + русский (украинский, беларуский) перевод.
Неважные типы (мост, тоннель) могут прекрасно использовать базовый перевод, чтобы не засорять файл переводов.

Разумно. Надо понимать, что многие наши типы, особенно highway.footway.bridge, это костыли для меньшего размера данных и более быстрой их обработки. По-хорошему, это были бы highway.footway с доп.признаками. И так для остальных примеров тоже. Но имеем что имеем, поэтому надо двигаться сюда: - Все отличающиеся по смыслу подтипы должны иметь хотя бы базовый английский + русский (украинский, беларуский) перевод. - Неважные типы (мост, тоннель) могут прекрасно использовать базовый перевод, чтобы не засорять файл переводов.

pastk reviewed 2022-01-05 18:42:11 +00:00

data/strings/types_strings.txt

					
				@ -7545,3 +7533,2 @@

				    de = Reitweg

				    fr = Chemin pour cavalier

				    ref = type.highway.bridleway

				    ja = 馬道(トンネル)

pastk commented

2022-01-05 18:42:11 +00:00

Разумно. Надо понимать, что многие наши типы, особенно highway.footway.bridge, это костыли для меньшего размера данных и более быстрой их обработки. По-хорошему, это были бы highway.footway с доп.признаками.

Было бы хорошо, да!

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

Для этого хорошо бы в перспективе сделать автоматическое добавление новых типов в types_strings.txt, типа как другие используемые строки грепаются в clean_strings_txt.py сейчас. Я уже штуки три нехватающих типа туда добавил, все их нашёл случайно, увидев в приложении идшку в PP subtitle.

* Неважные типы (мост, тоннель) могут прекрасно использовать базовый перевод, чтобы не засорять файл переводов.

Я бы на самом деле их все перевёл как "Мост" и "Тоннель", это более важная характеристика, чем тип дороги, проходящей через них (его можно при необходимости посмотреть, тапнув на подходящую к мосту дорогу). В таком случае выбор объектов по лонг тапу (когда это будет сделано) будет отлично заменять легенду (пару раз про неё юзеры уже спрашивали). Скажем, обозначение тоннеля не слишком очевидное (а для условной домохозяйки и обозначение моста в новинку будет).

> Разумно. Надо понимать, что многие наши типы, особенно highway.footway.bridge, это костыли для меньшего размера данных и более быстрой их обработки. По-хорошему, это были бы highway.footway с доп.признаками. Было бы хорошо, да! > * Все отличающиеся по смыслу подтипы должны иметь хотя бы базовый английский + русский (украинский, беларуский) перевод. Для этого хорошо бы в перспективе сделать автоматическое добавление новых типов в types_strings.txt, типа как другие используемые строки грепаются в clean_strings_txt.py сейчас. Я уже штуки три нехватающих типа туда добавил, все их нашёл случайно, увидев в приложении идшку в PP subtitle. > * Неважные типы (мост, тоннель) могут прекрасно использовать базовый перевод, чтобы не засорять файл переводов. Я бы на самом деле их все перевёл как "Мост" и "Тоннель", это более важная характеристика, чем тип дороги, проходящей через них (его можно при необходимости посмотреть, тапнув на подходящую к мосту дорогу). В таком случае выбор объектов по лонг тапу (когда это будет сделано) будет отлично заменять легенду (пару раз про неё юзеры уже спрашивали). Скажем, обозначение тоннеля не слишком очевидное (а для условной домохозяйки и обозначение моста в новинку будет).

vng (Migrated from github.com) reviewed 2022-01-05 18:44:19 +00:00

data/strings/types_strings.txt

					
				@ -7545,3 +7533,2 @@

				    de = Reitweg

				    fr = Chemin pour cavalier

				    ref = type.highway.bridleway

				    ja = 馬道(トンネル)

vng (Migrated from github.com) commented

2022-01-05 18:44:19 +00:00

Надо смотреть, но я согласен что базовый должен подниматься. Грубо говоря, мы переводим только highway и highway.bus_stop в виде исключения и все дороги будут подписываться.

pastk reviewed 2022-01-05 18:58:20 +00:00

data/strings/types_strings.txt

					
				@ -7545,3 +7533,2 @@

				    de = Reitweg

				    fr = Chemin pour cavalier

				    ref = type.highway.bridleway

				    ja = 馬道(トンネル)

pastk commented

2022-01-05 18:58:20 +00:00

Может проще и надёжнее поправить код, чтобы он брал перевод от базового типа, вместо этих усложнений? @vng а сейчас перевод не берётся у базового?

Я посмотрел код перевода типов, пусть @vng меня поправит, если я неправ.
Перевод берётся из нативных ios/android файлов локализации стандартными же методами (e.g. getString() в андроиде). В андроиде есть обёртка Utils::getLocalizedFeatureType(), она экспортируется в cpp-код и используется, например, для формирования PP subtitle там. Аналогично из iOS тоже в cpp своя функция локализации строк экспортируется. А, скажем, локализация списка типов/категорий в add place идёт целиком в андроиде, без заглядывания в cpp codebase.
Получается, что код придётся менять в нескольких местах (как минимум и в iOS, и в андроиде нужно понимать, вернул ли getString() язык X или дефолтный en, чтобы дальше опционально делать дефолт в базовый тип) и, возможно, дублировать саму логику дефолта в базовый тип (или реализовывать её в cpp, но тогда все использования перевода типов в андроиде, например, надо переделывать на вызовы cpp кода).
Имхо итого получится размазанно по нескольким кодовым базам, не проще, и не надёжнее, чем вот эта вот компактная реализация рефов в скрипте.

> Может проще и надёжнее поправить код, чтобы он брал перевод от базового типа, вместо этих усложнений? @vng а сейчас перевод не берётся у базового? Я посмотрел код перевода типов, пусть @vng меня поправит, если я неправ. Перевод берётся из нативных ios/android файлов локализации стандартными же методами (e.g. `getString()` в андроиде). В андроиде есть обёртка Utils::getLocalizedFeatureType(), она экспортируется в cpp-код и используется, например, для формирования PP subtitle там. Аналогично из iOS тоже в cpp своя функция локализации строк экспортируется. А, скажем, локализация списка типов/категорий в add place идёт целиком в андроиде, без заглядывания в cpp codebase. Получается, что код придётся менять в нескольких местах (как минимум и в iOS, и в андроиде нужно понимать, вернул ли getString() язык X или дефолтный en, чтобы дальше опционально делать дефолт в базовый тип) и, возможно, дублировать саму логику дефолта в базовый тип (или реализовывать её в cpp, но тогда все использования перевода типов в андроиде, например, надо переделывать на вызовы cpp кода). Имхо итого получится размазанно по нескольким кодовым базам, не проще, и не надёжнее, чем вот эта вот компактная реализация рефов в скрипте.

biodranik (Migrated from github.com) reviewed 2022-01-05 21:07:30 +00:00

data/strings/types_strings.txt

					
				@ -7545,3 +7533,2 @@

				    de = Reitweg

				    fr = Chemin pour cavalier

				    ref = type.highway.bridleway

				    ja = 馬道(トンネル)

biodranik (Migrated from github.com) commented

2022-01-05 21:07:30 +00:00

Исторически, предыдущие разработчики прикрутили типы в разных местах, потому что им так было проще. Но это по сути костыли. В идеале должен быть один источник строк, например, в С++, и оттуда уже код UI пускай получает, что отображать. Поддерживать такую реализацию очень легко.

Поэтому не хочется поверх текущих костылей лепить ещё новые.

Исторически, предыдущие разработчики прикрутили типы в разных местах, потому что им так было проще. Но это по сути костыли. В идеале должен быть один источник строк, например, в С++, и оттуда уже код UI пускай получает, что отображать. Поддерживать такую реализацию очень легко. Поэтому не хочется поверх текущих костылей лепить ещё новые.

biodranik (Migrated from github.com) reviewed 2022-01-05 21:10:32 +00:00

data/strings/types_strings.txt

					
				@ -7545,3 +7533,2 @@

				    de = Reitweg

				    fr = Chemin pour cavalier

				    ref = type.highway.bridleway

				    ja = 馬道(トンネル)

biodranik (Migrated from github.com) commented

2022-01-05 21:10:31 +00:00

Я бы на самом деле их все перевёл как "Мост" и "Тоннель", это более важная характеристика, чем тип дороги, проходящей через них

Это неплохая идея, но сейчас её непросто будет реализовать. Идея получше — выделить отдельные типы "мост" и "тоннель", и хранить их в списке типов фичи. Тогда можно будет показывать и "автострада * тоннель", что ещё лучше для пользователей. Кстати, @vng а почему мы так с самого начала не сделали?

На сколько я помню, сейчас за фичей может храниться до 7 разных типов из классификатора (@vng верно?)

> Я бы на самом деле их все перевёл как "Мост" и "Тоннель", это более важная характеристика, чем тип дороги, проходящей через них Это неплохая идея, но сейчас её непросто будет реализовать. Идея получше — выделить отдельные типы "мост" и "тоннель", и хранить их в списке типов фичи. Тогда можно будет показывать и "автострада * тоннель", что ещё лучше для пользователей. Кстати, @vng а почему мы так с самого начала не сделали? На сколько я помню, сейчас за фичей может храниться до 7 разных типов из классификатора (@vng верно?)

pastk reviewed 2022-01-06 08:45:51 +00:00

data/strings/types_strings.txt

					
				@ -7545,3 +7533,2 @@

				    de = Reitweg

				    fr = Chemin pour cavalier

				    ref = type.highway.bridleway

				    ja = 馬道(トンネル)

pastk commented

2022-01-06 08:45:51 +00:00

Исторически, предыдущие разработчики прикрутили типы в разных местах, потому что им так было проще. Но это по сути костыли. В идеале должен быть один источник строк, например, в С++, и оттуда уже код UI пускай получает, что отображать. Поддерживать такую реализацию очень легко.

Серьёзный такой рефакторинг.
Вообще, рефакторинг - это хорошо!
Но, на мой взгляд, в данной ситуации неоправданно:

решаемые проблемы незначительны по сравнению с необходимыми усилиями
сначала надо понять, будет ли переход на weblate и как - чтобы смотреть на всё более системно

Пока же, мне кажется, тут лучше придерживаться подхода "работает - не трогай".

Поэтому не хочется поверх текущих костылей лепить ещё новые.

Ссылки (refs) это существующая фича твайна (я понимаю, что можно смотреть на весь твайн, как на костыль - всё относительно :))
Я сначала сомневался в их полезности, но тут они очень пригодились, чтобы растиражировать новые переводы по куче копий и дедублицировать эти копии, причём так, чтобы не затереть уже сделанные некоторыми переводчиками более точные переводы, например:

  [type.highway.motorway_link]
    ref = type.highway.motorway
    en = Motorway Ramp
    de = Autobahnauffahrt
    pt = Ligação a autoestrada
    ru = Съезд с автомагистрали
    zh-Hans = 高速公路连接路
    zh-Hant = 高速公路連接路

Руками сделать это было бы очень муторно и легко было бы наделать ошибок.
Мои дополнения в strings_utils.py по сути просто автоматизируют эту работу.

В итоге - почищенный файл, в котором удобнее и добавлять, и обновлять переводы.

Более того, в случае предложенного вами рефакторинга всё равно понадобится какой-то скрипт дедубликации существующих переводов (я уже начал эту работу :)).

В общем, прошу попробовать посмотреть на этот PR не как на новый костыль, а как на причёсывание того, что есть, первые шажки в длинном пути рефакторинга и incremental improvement :)

> Исторически, предыдущие разработчики прикрутили типы в разных местах, потому что им так было проще. Но это по сути костыли. В идеале должен быть один источник строк, например, в С++, и оттуда уже код UI пускай получает, что отображать. Поддерживать такую реализацию очень легко. > Серьёзный такой рефакторинг. Вообще, рефакторинг - это хорошо! Но, на мой взгляд, в данной ситуации неоправданно: - решаемые проблемы незначительны по сравнению с необходимыми усилиями - сначала надо понять, будет ли переход на weblate и как - чтобы смотреть на всё более системно Пока же, мне кажется, тут лучше придерживаться подхода "работает - не трогай". > Поэтому не хочется поверх текущих костылей лепить ещё новые. Ссылки (refs) это существующая фича твайна (я понимаю, что можно смотреть на весь твайн, как на костыль - всё относительно :)) Я сначала сомневался в их полезности, но тут они очень пригодились, чтобы растиражировать новые переводы по куче копий и дедублицировать эти копии, причём так, чтобы не затереть уже сделанные некоторыми переводчиками более точные переводы, например: ``` [type.highway.motorway_link] ref = type.highway.motorway en = Motorway Ramp de = Autobahnauffahrt pt = Ligação a autoestrada ru = Съезд с автомагистрали zh-Hans = 高速公路连接路 zh-Hant = 高速公路連接路 ``` Руками сделать это было бы очень муторно и легко было бы наделать ошибок. Мои дополнения в `strings_utils.py` по сути просто автоматизируют эту работу. В итоге - почищенный файл, в котором удобнее и добавлять, и обновлять переводы. Более того, в случае предложенного вами рефакторинга всё равно понадобится какой-то скрипт дедубликации существующих переводов (я уже начал эту работу :)). В общем, прошу попробовать посмотреть на этот PR не как на новый костыль, а как на причёсывание того, что есть, первые шажки в длинном пути рефакторинга и incremental improvement :)

biodranik (Migrated from github.com) reviewed 2022-01-06 21:04:00 +00:00

data/strings/types_strings.txt

					
				@ -7545,3 +7533,2 @@

				    de = Reitweg

				    fr = Chemin pour cavalier

				    ref = type.highway.bridleway

				    ja = 馬道(トンネル)

biodranik (Migrated from github.com) commented

2022-01-06 21:04:00 +00:00

Ладно, пускай будет. Только надо будет сделать подробный issue для рефакторинга.

biodranik (Migrated from github.com) approved these changes 2022-01-06 21:04:11 +00:00

This repo is archived. You cannot comment on pull requests.

No reviewers

biodranik

No labels

Android Automotive (AAOS)

API

AppGallery

AppStore

Battery and Performance

External Map Datasets

F-Droid

Fonts

Frequently User Reported

No milestone

No project

No assignees

2 participants

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: organicmaps/organicmaps-tmp#1779

Rows
Columns