Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@holidays/locale/kn/LC_MESSAGES/IN.po`:
- Around line 39-43: The Kannada translation for the msgid "Dr. B. R. Ambedkar's
Jayanti" has a typo in msgstr ("ಡಾ|| ಬಿ.ಆರ್.ಅಂಬೇಡ್ಕರ್ ಜಯಂತಿ"); edit the msgstr
for that exact msgid to replace the incorrect "ಡಾ||" with the correct "ಡಾ." so
the entry reads "ಡಾ. ಬಿ.ಆರ್.ಅಂಬೇಡ್ಕರ್ ಜಯಂತಿ".

---

Duplicate comments:
In `@holidays/locale/ta/LC_MESSAGES/IN.po`:
- Around line 103-105: The translator comment for the entry with msgid
"Id-ul-Zuha (Bakrid)" is incorrect ("Eid al-Adha"); update the source comment in
the Python code that generates this catalog so the translator comment matches
the msgid (or the canonical event name) and then regenerate the .po files by
running make l10n, ensuring the PO entry for msgid "Id-ul-Zuha (Bakrid)" in
LC_MESSAGES/IN.po (and other locales) carries the corrected translator comment.

In `@holidays/locale/te/LC_MESSAGES/IN.po`:
- Around line 103-105: The translator comment above the msgid is incorrect;
replace or update the comment to match the msgid "Id-ul-Zuha (Bakrid)" (e.g.,
change the existing comment "Eid al-Adha." to "Id-ul-Zuha (Bakrid).") so the
comment and msgid are consistent; apply the same correction pattern used in
other locale files where this mismatch occurred.

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="holidays/locale/hi/LC_MESSAGES/IN.po">

<violation number="1" location="holidays/locale/hi/LC_MESSAGES/IN.po:56">
P3: Extracted comment doesn't match the Python source comment (`# Diwali.` at india.py:214). This should be `#. Diwali.` to be consistent with how other entries work (e.g., `#. Eid al-Adha.` for msgid `"Id-ul-Zuha (Bakrid)"`). Consider regenerating via `make l10n` rather than hand-editing.

(Based on your team's feedback about managing translation files through the l10n pipeline.) [FEEDBACK_USED]</violation>
</file>

<file name="holidays/countries/india.py">

<violation number="1" location="holidays/countries/india.py:194">
P2: Now that "Dr. B. R. Ambedkar's Jayanti" is added as a national public holiday, the same `_add_holiday_apr_14` calls in ~25 subdivision methods (AN, AP, BR, CH, CG, GA, GJ, HR, HP, JK, JH, KA, KL, LA, MH, MP, OD, PY, PB, RJ, SK, TN, TS, UK, UP, WB) are redundant. Other national holidays (Republic Day, Independence Day, Gandhi Jayanti) are not repeated at the subdivision level. These subdivision-level additions should be removed to follow the same pattern.</violation>
</file>

<file name="holidays/locale/gu/LC_MESSAGES/IN.po">

<violation number="1" location="holidays/locale/gu/LC_MESSAGES/IN.po:56">
P2: This `.po` file appears to have been hand-edited rather than generated via `make l10n`. The extracted comments (`#.` lines) differ from the `en_IN` reference locale — e.g., Diwali's comment here is `#. Diwali (Deepavali).` while the generated reference has `#. Diwali.`, and multi-line extracted comments for Ambedkar and Janmashtami are missing. Run `make l10n` to regenerate the file from source, then fill in the `msgstr` translations.

(Based on your team's feedback about managing translation files through the l10n pipeline.) [FEEDBACK_USED]</violation>
</file>

<file name="holidays/locale/en_US/LC_MESSAGES/IN.po">

<violation number="1" location="holidays/locale/en_US/LC_MESSAGES/IN.po:41">
P2: This extracted comment doesn't match any source code comment — all instances in `india.py` use `"Dr. B. R. Ambedkar's Jayanti"` (with possessive 's). This stale comment suggests the file was hand-edited rather than regenerated via `make l10n`. Run `make l10n` to keep the .po file consistent with source strings.

(Based on your team's feedback about managing translation files through the l10n pipeline.) [FEEDBACK_USED]</violation>
</file>

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@holidays/calendars/hindu.py`:
- Line 1170: The RAM_NAVAMI_DATES table in _HinduLunisolar (symbol:
_HinduLunisolar.RAM_NAVAMI_DATES) incorrectly encodes an observance shift for
2008 as (APR, 14); revert that entry to the true astronomical date (APR, 13) so
the shared lunisolar calendar remains raw, and let the India observance pipeline
(see india.py and the _add_observed(..., rule=SUN_TO_NONE) / SUN_ONLY logic)
perform the gazette transfer to Apr 14 for India-specific PUBLIC holidays.

In `@holidays/countries/india.py`:
- Around line 235-252: The current hard-coded exclusion set around the Maha
Shivaratri addition is brittle and may be wrong; replace the inline literal set
with a single named constant (e.g. MAHA_SHIVARATRI_OBSERVED_YEARS) and decide
whether an inclusion set (years when Maha Shivaratri is observed) or an
exclusion set is correct based on the official notices — if the observed years
are the smaller group, invert the logic to check membership in the inclusion
constant; update the check in the method where
self._add_maha_shivaratri(tr("Maha Shivaratri")) is called and mirror the exact
same constant/logic in the optional-category counterpart (the block that
currently spans lines ~311-328) so both stay in sync.
- Around line 197-198: Remove the duplicate per-subdivision Ambedkar Jayanti
entries now that it's added nationally: find the per-subdivision population
methods (the various _populate_subdiv_*_public_holidays methods) and delete the
calls to self._add_holiday_apr_14(tr("Dr. B. R. Ambedkar's Jayanti")) for the
listed subdivisions (AN, AP, BR, CH, CG, GA, GJ, HR, HP, JK, JH, KA, KL, LA, MH,
MP, OD, PY, PB, RJ, SK, TN, TS, UK, UP, WB), leaving only the national-level
self._add_holiday_apr_14(...) in the main _populate_public_holidays;
alternatively, if you prefer the gated approach, replace those subdivision calls
with a single conditional in the subdivision dispatcher that adds Ambedkar
Jayanti only when subdiv not in {"AS","DL","MZ","NL"} using the existing
self._add_holiday_apr_14 method.
- Around line 301-303: Replace the boolean chain checking specific years with a
set membership test: in the block that currently tests "if self._year == 2008 or
self._year == 2017" use a set (or tuple) membership check against self._year
(matching the style used at the public counterpart around line 228) and keep the
call to self._add_janmashtami(tr("Janmashtami (Vaishnava)")) unchanged; this
consolidates the year checks into a single efficient expression.
- Around line 569-572: Remove the duplicate Ambedkar Jayanti entry (the
self._add_holiday_apr_14(tr("Dr. B. R. Ambedkar's Jayanti")) call) from the
Tamil Nadu section and keep the Puthandu entry, but replace the hardcoded
self._add_holiday_apr_14(tr("Puthandu (Tamil New Year)")) with a calendar-driven
helper like _add_puthandu or compute_puthandu_date that mirrors the approach
used for Pongal/Thiruvalluvar Day (use the existing calendar helper patterns to
compute Mesha Sankranti/solar transit into Aries and return Apr 13–15 as
appropriate, falling back to Apr 14 if computation fails), and call that helper
instead of the static _add_holiday_apr_14; ensure to use the same tr(...) label
when adding the computed date.

In `@tests/countries/test_india.py`:
- Around line 313-314: The test_dussehra_mahanavami currently only asserts a
single date ("2002-10-14"); replace or augment that with a full-range check
using the _assertHinduHolidayHelper to validate the holiday across
hindu_start_year..hindu_end_year and confirm absence outside that range, and if
this is meant to be a single-year variant, explicitly assert absence for the
adjacent years (e.g., years before and after 2002) so the test locks in that
behavior; update references to _assertHinduHolidayHelper and keep or remove the
single assertHolidayName("Dussehra (Mahanavami)", "2002-10-14") accordingly.
- Around line 234-253: The else branch inside the category_optional=True
handling incorrectly calls assertNoHolidayName(name) for the entire catalog when
skip_years is empty, which conflicts with prior public assertions; remove that
else branch (or make it an opt-in flag) so the helper only asserts optional-side
facts (assertOptionalHolidayName, assertOptionalNonObservedHolidayName,
assertNoOptionalHolidayName, assertNoOptionalNonObservedHolidayName) and do not
call assertNoHolidayName(name) unless the caller explicitly requests it or
provides skip_years; update callers that expect a pure “no-public” assertion to
call assertNoHolidayName(name) themselves.

---

Outside diff comments:
In `@tests/countries/test_india.py`:
- Around line 186-215: Fix two docstring issues in the helper in
tests/countries/test_india.py: correct the typo by adding a space after the
comma in "skip_years, works" (near the parameter description for skip_years) and
replace the over-specific SUN_TO_NONE explanation with a shorter, generic
sentence such as "the range-wide assertion uses the non-observed catalog, so
observance shifts don't affect membership" (update the paragraph that currently
references SUN_TO_NONE/observance rules). Ensure edits are made inside the same
docstring that documents hindu_range and skip_years so the helper signature
(hindu_range, skip_years) remains unchanged.
- Around line 316-333: The test_janmashtami_vaishnava currently asserts the
holiday as public for certain years then calls the helper with
category_optional=True without supplying skip_years, which makes the helper call
assertNoHolidayName(name) for the entire catalog and causes a collision; fix by
removing the redundant self.assertNoHolidayName(name, 2008, 2017) and call
self._assertHinduHolidayHelper(name, dts, category_optional=True,
skip_years=(2020,2021,2022,2023,2024,2025)) (or the equivalent tuple of public
years) so the helper will skip those public years when asserting optional-only
absence via assertNoOptionalHolidayName and avoid contradicting the earlier
public assertions.
- Around line 179-275: The helper _assertHinduHolidayHelper has inverted
semantics for skip_years vs caller intent; remove the skip_years parameter and
its handling (the effective_range computation that filters out skip_years) and
require callers (e.g., test_maha_shivaratri and test_ram_navami) to pass the
exact years via hindu_range (or self.hindu_full_range) so the helper only uses
hindu_range directly; update the helper signature to drop skip_years, delete the
lines computing effective_range from skip_years, adjust callers to pass
hindu_range=(...) or hindu_range=self.hindu_full_range as appropriate, and add a
one-line note in the helper docstring that callers must pass explicit
hindu_range when they need a subset.
- Around line 496-519: The non-optional Ram Navami test calls
_assertHinduHolidayHelper(name, dts) but fails because it asserts the holiday
across the entire self.hindu_full_range; include a skip_years argument listing
years that are optional-only (e.g., the set used in the optional block: {2002,
2012, 2018, 2022, 2025, 2029}) when calling _assertHinduHolidayHelper for the
non-optional path (reference _assertHinduHolidayHelper and the variable dts),
and replace the confusing inverted-set expression in the optional call with an
explicit hindu_range or explicit skip_years list to make the intent clear.
- Around line 734-770: The test test_dr_b_r_ambedkars_jayanti fails because "Dr.
B. R. Ambedkar's Jayanti" is registered both nationally and again in 26
subdivisions; choose one approach—here, make it selective: remove the
national-level registration of the holiday (the generator/registration that
creates a nationwide "Dr. B. R. Ambedkar's Jayanti" entry) so only the explicit
subdiv registrations remain, leaving test_dr_b_r_ambedkars_jayanti's current
assertions valid.

---

Duplicate comments:
In `@holidays/locale/kn/LC_MESSAGES/IN.po`:
- Around line 39-42: Replace the typo in the Kannada translation for the msgid
"Dr. B. R. Ambedkar's Jayanti": update the msgstr value currently containing
"ಡಾ|| ಬಿ.ಆರ್.ಅಂಬೇಡ್ಕರ್ ಜಯಂತಿ" to use a period instead of double pipes, i.e. "ಡಾ.
ಬಿ.ಆರ್.ಅಂಬೇಡ್ಕರ್ ಜಯಂತಿ", preserving spacing and punctuation.

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="holidays/locale/ml/LC_MESSAGES/IN.po">

<violation number="1" location="holidays/locale/ml/LC_MESSAGES/IN.po:20">
P2: This `.po` file appears to be hand-edited rather than regenerated via `make l10n`. Update the source strings in the Python code, then run `make l10n` to regenerate the translation files to maintain consistent formatting and entry ordering.

(Based on your team's feedback about managing translation files through the l10n pipeline.) [FEEDBACK_USED]</violation>
</file>

<file name="holidays/locale/en_US/LC_MESSAGES/IN.po">

<violation number="1" location="holidays/locale/en_US/LC_MESSAGES/IN.po:20">
P2: This `.po` file appears to be hand-edited rather than regenerated via `make l10n`. The proper workflow is to update the source `.py` holiday strings first, then run `make l10n` to let the tooling regenerate this file with consistent ordering and metadata.

(Based on your team's feedback about managing translation files through the l10n pipeline.) [FEEDBACK_USED]</violation>
</file>

<file name="holidays/locale/hi/LC_MESSAGES/IN.po">

<violation number="1" location="holidays/locale/hi/LC_MESSAGES/IN.po:20">
P2: This `.po` file appears to be hand-edited rather than generated by `make l10n`. The project has an l10n pipeline (`make l10n` → `generate_po_files.py`) that should produce these files from the source `.py` strings. Please update the source strings in `india.py` first (if not already done), then run `make l10n` to regenerate the `.po` file to ensure it stays in sync with the tooling's expected format and ordering.

(Based on your team's feedback about managing translation files through the l10n pipeline.) [FEEDBACK_USED]</violation>
</file>

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@tests/countries/test_india.py`:
- Around line 323-330: The split-holiday tests call the helper and
assertNoHolidayName across public vs optional halves but don't pass the same
skip_years to both, causing conflicting assertions; update the test cases (e.g.,
test_janmashtami_vaishnava, test_ram_navami and similar blocks around the shown
diff) so that both calls to self._assertHinduHolidayHelper and
self.assertNoHolidayName include the same skip_years argument (or pass
skip_years to both helper invocations) so the public-side and optional-side
checks consistently skip the same years.
- Around line 183-184: The annotations use Iterable in the function signature
containing parameters "hindu_range: Iterable[int] | None" and "skip_years:
set[int] | None" but Iterable is not imported; add "from typing import Iterable"
(or include Iterable in the existing typing import) at the top of the module so
the annotation resolves at import time (alternatively enable postponed
evaluation with "from __future__ import annotations" if you prefer).

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="holidays/countries/india.py">

<violation number="1" location="holidays/countries/india.py:259">
P1: The new common Holi addition creates a conflicting duplicate Holi date for Maharashtra (notably 2026), because MH already defines its own public Holi date override.</violation>
</file>

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@tests/countries/test_india.py`:
- Around line 255-273: The helper contains stale commented-out assertions
(references: assertHolidayName, assertNoHolidayName,
assertNoSuNonObservedHolidayName, assertNoNonObservedHolidayName and variables
subdivs, subdiv, holidays, non_obs_holidays) which should be removed or
reinstated; either fully delete the commented blocks (the three commented
assert* lines and the commented non_obs_holidays line) to keep the helper
concise, or re-enable them by restoring correct current semantics (uncomment and
update arguments/variable names to match the active code) so there are no stray
commented assertions remaining.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@holidays/groups/hindu.py`:
- Around line 31-36: The `_ram_navami` property is missing a return type
annotation. Add the return type annotation `date | None` to the property
definition, as it returns the first element of the tuple from `ram_navami_date`
which can be either a date object or None. This ensures consistency with type
annotation standards throughout the codebase.

In `@holidays/locale/kn/LC_MESSAGES/IN.po`:
- Around line 215-218: The msgstr value for "Ganesh Chaturthi / Vinayak
Chaturthi" in the Kannada locale file is written in Malayalam script instead of
Kannada script. Replace the Malayalam text in the msgstr field with the correct
Kannada script translation to ensure Kannada users receive the proper locale
output. The msgid identifier "Ganesh Chaturthi / Vinayak Chaturthi" marks the
exact entry that needs correction.

In `@holidays/locale/ml/LC_MESSAGES/IN.po`:
- Around line 451-453: The msgstr for "Janmashtami (Smarta)" in the Malayalam
locale file (holidays/locale/ml/LC_MESSAGES/IN.po) is currently written in
Kannada script instead of Malayalam script, breaking the Malayalam localization.
Replace the Kannada script translation (ಜನ್ಮಾಷ್ಟಮಿ (ಸ್ಮಾರ್ತ)) with the correct
Malayalam script translation for this holiday to ensure proper localization for
Malayalam users.

In `@holidays/locale/mr/LC_MESSAGES/IN.po`:
- Around line 451-453: The msgstr value for the message ID "Janmashtami
(Smarta)" in the Marathi locale file is currently written in Kannada script
instead of Marathi script. Replace the Kannada script text in the msgstr field
with the correct Marathi script translation for "Janmashtami (Smarta)" to ensure
the Marathi localization output displays correctly.

In `@holidays/locale/te/LC_MESSAGES/IN.po`:
- Around line 183-185: The Telugu locale catalog file
(holidays/locale/te/LC_MESSAGES/IN.po) contains three entries where the msgstr
values are written in Tamil script instead of Telugu script, which will cause
incorrect rendering for Telugu users. At lines 183-185 (Vaisakhadi entry), lines
191-193, and lines 263-265, replace each Tamil-script msgstr value with the
correct Telugu-script translation for the corresponding holiday name to ensure
the Telugu localization displays properly.