Catalan and Norwegian AI localization

[amikhaylin]

No description provided.

[github-actions]

Code review by ChatGPT

[github-actions]

Ниже — только замечания по сути.

Критичные/функциональные:

• Вы убрали правило для .build/ (SwiftPM). Это приведет к попаданию билд‑артефактов SPM в репозиторий. Верните игнорирование .build/ (лучше без ведущего слэша: ".build/" — чтобы сработало и для вложенных пакетов).
• Изменили якорение некоторых путей (убрали ведущий / у DerivedData/ и TestResults*/). Теперь они будут игнорироваться в любом подкаталоге, что может скрывать нерелевантные файлы/папки. Определитесь с намерением и сделайте последовательно:
  • Если хотите игнорировать только в корне — используйте ведущий слэш: "/DerivedData/", "/TestResults*/", "/build/".
  • Если хотите игнорировать в любом месте — без слэша: "DerivedData/", "TestResults*/", "build/".
    Сейчас смешанный подход может быть источником неожиданностей.

Хорошие изменения, но с нюансами:

• ".xcresult" — верно, предыдущее "/.xcresult" почти бесполезно. Оставляйте как есть.
• Добавили покрытия (*.xccovreport, *.xccovarchive, *.profdata) — ок.

Рекомендации по полноте/актуальности:

• Добавьте типичные Xcode‑мусоры:
  • "*.xcuserstate"
  • "project.xcworkspace/xcshareddata/IDEWorkspaceChecks.plist"
  • "project.xcworkspace/xcshareddata/WorkspaceSettings.xcsettings"
• dSYM: дополнительно игнорируйте "*.dSYM.zip" (часто экспортируются так).
• Package Manager:
  • "Package.pins" устарел — можно удалить из .gitignore (не используется современным SPM).
  • Определитесь с "Package.resolved": для приложений его обычно коммитят (для воспроизводимости), для библиотек часто игнорируют. Сейчас он не игнорируется — это нормально для приложений.
• .swiftpm/: в целом корректно игнорировать целиком. Если у вас есть редкие случаи, когда что‑то из .swiftpm нужно коммитить — уточните исключения.
• .doccarchive: игнорируйте, только если точно не храните собранную документацию в репозитории. Иначе — уберите правило.
• Приведите стиль к единообразию (ведущий слэш да/нет) для раздела Build/Artifacts — это упростит поддержку и исключит ложные срабатывания.

Итого минимальные правки:

• Вернуть: ".build/"
• Принять решение и унифицировать якорение для: DerivedData/, TestResults*/, build/
• Добавить: ".xcuserstate", "project.xcworkspace/xcshareddata/IDEWorkspaceChecks.plist", "project.xcworkspace/xcshareddata/WorkspaceSettings.xcsettings", ".dSYM.zip"
• Пересмотреть необходимость "Package.pins" и ".doccarchive" согласно вашему процессу.

[github-actions]

Коротко по делу:

• Если вы по‑прежнему добавляете события через EventKit, удаление NSCalendarsWriteOnlyAccessUsageDescription опасно: при запросе write-only доступа на iOS 17+ приложение упадет с исключением из‑за отсутствия ключа в Info.plist. Верните ключ или смените стратегию доступа.

• Определитесь с моделью доступа на iOS 17+:

  • write-only: нужен NSCalendarsWriteOnlyAccessUsageDescription
  • full access: нужен NSCalendarsFullAccessUsageDescription
    На iOS ≤16 по‑прежнему обязателен NSCalendarsUsageDescription, независимо от выбора на iOS 17+.

• Если поддерживаете iOS 16 и ниже, итоговый набор ключей должен быть:

  • Для write-only: NSCalendarsUsageDescription + NSCalendarsWriteOnlyAccessUsageDescription
  • Для full access: NSCalendarsUsageDescription + NSCalendarsFullAccessUsageDescription

• Проверьте код запросов прав:

  • Для write-only:
    • iOS 17+: EKEventStore.requestWriteOnlyAccessToEvents()
    • iOS ≤16: EKEventStore.requestAccess(to: .event)
  • Для full access:
    • iOS 17+: EKEventStore.requestFullAccessToEvents()
    • iOS ≤16: EKEventStore.requestAccess(to: .event)
      Несоответствие типа запроса и наличия нужного ключа в Info.plist приведет к крэшу.

• Если вы полностью отказались от работы с календарем, удаление ключа корректно. Заодно удалите EventKit из линковки и код, чтобы не появляться в Privacy Report/App Store Privacy.

• Строки причин должны быть информативными и локализованными. “Adding events to your calendars” слишком общая; лучше объяснить конкретный сценарий использования.

• UIBackgroundModes = remote-notification: убедитесь, что действительно используете «тихие» пуши (content-available) или иные сценарии, требующие этого режима. Лишний фоновый режим может вызвать вопросы на ревью.

• Рекомендую добавить CI-проверку соответствия: если в коде встречаются вызовы EventKit-запросов, проверяйте наличие нужных Info.plist ключей для вашей матрицы iOS (скриптом на plutil + простым grep по исходникам). Это поймает подобные регрессии до ревью.

[github-actions]

Коротко по делу:

• Изменение — чисто перестановка записи "SL8-VU-Gud.title" (Cancel). Функционального эффекта нет, это лишь добавляет шум в истории и повышает вероятность конфликтов при мерджах. Я бы не принимал такой PR без причины.

Рекомендации по улучшению процесса/файла:

• Детерминированный порядок ключей:

  • Либо группируйте логически (OK/Cancel рядом).
  • Либо сортируйте ключи стабильно (по ключу), но делайте это инструментом, который сохраняет комментарии к записям (например, через ibtool/xcodebuild экспорт-импорт локализаций, а не ручной sort).
  • Добавьте проверку в CI, чтобы порядок был консистентным и не было «пустых» диффов.

• Проверка валидности:

  • Прогоняйте plutil -lint для .strings в CI.
  • Зафиксируйте кодировку (UTF-8) и финальную новую строку — чтобы избежать платформенных диффов.

• Контент:

  • Убедитесь, что “PomPadDoExt” действительно должен локализоваться. Если это название продукта, обычно его не переводят; лучше исключить из локализации/пометить как Do Not Localize.
  • Placeholder’ы “Link” и “Name”: если они неоднозначны для переводчиков, добавьте уточняющие комментарии (но помните, что IB может перегенерировать файл и стереть ручные комментарии; лучше хранить эти пояснения в XLIFF-потоке или в документации для переводчиков).

• Процесс с Interface Builder:

  • Избегайте ручного редактирования .strings, которые генерирует IB. Любые «косметические» правки (вроде перестановки) IB может перезаписать при следующей синхронизации.
  • Если проект на Xcode 15+, рассмотрите переход на String Catalogs для строк из кода. Для IB-строк всё ещё будут .strings/XLIFF, но общий процесс локализации станет стабильнее.

Итого: текущий PR — безрезультатный реордер. Либо верните исходное расположение, либо через инструментальную сортировку зафиксируйте единый порядок по всему проекту и автоматизируйте проверку в CI. Дополнительно проверьте необходимость локализации названия “PomPadDoExt”.

[github-actions]

Ниже только то, что реально может укусить в сборке, релизе или ревью. Без похвал и очевидностей.

Блокирующие/высокий риск

• MACOSX_DEPLOYMENT_TARGET = 26.0 — это некорректно. Для macOS сейчас валидные версии ~10.13–15.0. Похоже на промах по платформе (вместо WATCHOS_DEPLOYMENT_TARGET или XROS_DEPLOYMENT_TARGET). Исправьте на реальную минимальную версию macOS или на правильный ключ деплоймента для нужной платформы.
• Несогласованность deployment target’ов. Для ряда iOS-расширений явно стоит IPHONEOS_DEPLOYMENT_TARGET = 18.1, а у основного iOS-приложения не видно явного таргета (может быть ниже/выше по умолчанию). App Store завернёт, если extension требует более новой ОС, чем контейнер. Выставьте одинаковый минимум на уровне проекта и позвольте таргетам наследовать.
• Календарные ключи приватности. Вы добавили NSCalendarsWriteOnlyAccessUsageDescription, но:
  • Если в коде где-то есть чтение календарей или запрос на full access — потребуется NSCalendarsFullAccessUsageDescription (иначе падение при запросе).
  • Если поддерживаются iOS < 17 / macOS < 14 — для совместимости нужен старый NSCalendarsUsageDescription.
  • Убедитесь, что все расширения, которые трогают EventKit (App Intents, Intents Extension, возможно watch extension), тоже содержат нужные ключи в своём Info.plist. Виджетам обычно нельзя дергать EventKit, но другие экстеншены — да.

Серьезные улучшения/поддерживаемость

• Дублирование CURRENT_PROJECT_VERSION. Вы подняли до 90 в десятках конфигураций. Вынесите в:
  • уровень проекта (Project > Build Settings) или
  • .xcconfig (рекомендуется).
    Это снизит риск рассинхронизации. Аналогично для MARKETING_VERSION.
• Гарантируйте, что CFBundleVersion действительно берёт значение из CURRENT_PROJECT_VERSION в таргетах с кастомными Info.plist (у вас не везде GENERATE_INFOPLIST_FILE = YES). Либо пропишите CFBundleVersion = $(CURRENT_PROJECT_VERSION) в Info.plist, либо добавьте INFOPLIST_KEY_CFBundleVersion = $(CURRENT_PROJECT_VERSION) в Build Settings таргетов.
• Локализация purpose string. Вы добавили ca и nb в knownRegions — тогда как минимум добавьте локализации строки NSCalendarsWriteOnlyAccessUsageDescription через InfoPlist.strings (или примите, что будет английский фоллбек). Лучше сделать текст более предметным (зачем именно приложению это нужно), это снижает риск вопросов на ревью.
• Проверка наличия .lproj. Раз добавлены ca и nb в knownRegions, проверьте, что соответствующие каталоги *.lproj реально есть в проекте и подключены к нужным таргетам, иначе Xcode будет ругаться/игнорировать.

Платформенные нюансы

• macOS sandbox: если на macOS действительно обращаетесь к календарям — проверьте наличие entitlement’а com.apple.security.personal-information.calendars (без него доступ будет блокироваться независимо от ключей в Info.plist).
• У watchOS- и widgets-таргетов нет явных deployment target’ов в диффе. Убедитесь, что они согласованы с iOS-таргетом и не тащат более новый минимум, чем контейнер.

Мелкое, но полезное

• Для ключей приватности в Build Settings вы используете INFOPLIST_KEY_* — это норм. Для единообразия и предотвращения расхождений заведите единый .xcconfig для ключей приватности по платформам (iOS/macOS), чтобы не править одно и то же в нескольких местах.
• Проверка CFBundleDisplayName: вы задаете одно значение через INFOPLIST_KEY_CFBundleDisplayName. Если планируется локализованное имя приложения для новых языков, добавьте InfoPlist.strings (ca, nb).

Р 요 краткий чек-лист фиксов

• Исправить MACOSX_DEPLOYMENT_TARGET = 26.0 → корректное значение/ключ для нужной платформы.
• Выставить общий IPHONEOS_DEPLOYMENT_TARGET на уровне проекта и удалить переопределения, где не требуется.
• Добавить недостающие ключи приватности при необходимости: NSCalendarsFullAccessUsageDescription и/или NSCalendarsUsageDescription (если поддерживаете старые ОС).
• Добавить эти ключи в Info.plist соответствующих экстеншенов, если они используют EventKit.
• Вынести CURRENT_PROJECT_VERSION и MARKETING_VERSION в проект или .xcconfig; гарантировать подстановку CFBundleVersion.
• Локализовать NSCalendarsWriteOnlyAccessUsageDescription (минимум для ca, nb) или принять осознанно английский фоллбек.
• Проверить наличие .lproj для ca и nb.
• Для macOS — проверить entitlement на доступ к календарям.

[github-actions]

Основное замечание: вы удалили NSCalendarsWriteOnlyAccessUsageDescription. Это безопасно только если приложение больше не запрашивает “write‑only” доступ к календарям (EKEventStore.requestWriteOnlyAccessToEvents на iOS 17+). В противном случае на iOS 17+ получите падение при запросе разрешения и/или отклонение при ревью.

Что проверить и как улучшить:

• Если вы по‑прежнему добавляете события без чтения календарей на iOS 17+: верните ключ NSCalendarsWriteOnlyAccessUsageDescription. Лучше оставить и NSCalendarsUsageDescription, и NSCalendarsWriteOnlyAccessUsageDescription, так как:
  • iOS < 17 использует requestAccess(to: .event) → требует NSCalendarsUsageDescription.
  • iOS 17+ при requestWriteOnlyAccessToEvents требует именно NSCalendarsWriteOnlyAccessUsageDescription.
• Если вы переходите на полный доступ (requestAccess(to: .event)): убедитесь, что NSCalendarsUsageDescription присутствует. Также оцените, действительно ли нужен полный доступ — с точки зрения принципа наименьших привилегий правильнее write‑only, если вы ничего не читаете из календарей.
• Если вы “перенесли” текст в InfoPlist.strings: удаление ключа из Info.plist может быть проблемой. Убедитесь, что ключ существует во всех локализациях (включая Base). В противном случае на некоторых локалях будет отсутствие usage‑строки и краш. Практичный вариант — оставить ключ в Info.plist с дефолтным текстом и переопределять его через InfoPlist.strings.
• Тестовый чек‑лист:
  • На устройстве с iOS 17+ пройти путь запроса write‑only разрешения — без ключа будет немедленный краш.
  • Статическая проверка сборки/CI: убедиться, что при линковке с EventKit и наличии вызова requestWriteOnlyAccessToEvents в бандле присутствует NSCalendarsWriteOnlyAccessUsageDescription.
• Качество формулировки: если возвращаете ключ, сделайте текст более конкретным и объясняющим пользу для пользователя (что именно добавляем и зачем), и локализуйте.

Итого: удаление NSCalendarsWriteOnlyAccessUsageDescription — потенциальная регрессия. Либо верните ключ (и держите оба, write‑only и общий), либо подтвердите, что код больше не запрашивает write‑only доступ на iOS 17+.

[github-actions]

Коротко и по делу:

• Уточните «Norwegian»: это обычно «Norwegian Bokmål (nb)» или «Norwegian Nynorsk (nn)». Просто «Norwegian» неоднозначно и может ввести в заблуждение. В README лучше явно указать вариант и синхронизировать с кодом/локалями Xcode. Избегайте устаревшего кода «no».

• Проверьте соответствие с реальными локалями в проекте:

  • Наличие каталогов ca.lproj и nb.lproj/nn.lproj (Localizable.strings, InfoPlist.strings).
  • Обновлен ли CFBundleLocalizations (если используете явное перечисление).
  • Тест на выбор языка через iOS Settings → App Language.

• Консистентность наименований: в списке есть «Chinese», «Persian» и т. п. Если где-то уже используется более точная формулировка (например, «Chinese (Simplified/Traditional)» или «Farsi/Persian»), приведите к единому стилю. Для Norwegian — обязательно.

• Порядок алфавитный соблюден, но добавьте автоматическую проверку (скрипт/линтер для README), чтобы при будущих PR не было нарушений сортировки/дубликатов.

• Мелочь, но полезно: уберите хвостовой пробел у «Bulgarian » в существующей строке — снизит «шум» в будущих диффах.

• Если в приложении есть экран выбора языка, убедитесь, что названия там совпадают с README и (желательно) даны на родном языке пользователя («Català», «Norsk bokmål») либо последовательно на английском — главное, единообразие.

• Поскольку раздел помечен как «AI-based localizations», стоит кратко указать в README оговорку о качестве и способ предложить правки (ссылка на Crowdin/POEditor/PR-гайд), чтобы ожидания пользователей были корректными.

В остальном добавления корректны и на своих местах (алфавит, формат маркеров).