Repository navigation
fix(mobile): use the open state form and one finding noun in Arabic - #9342
Conversation
The Arabic catalog rendered the open finding status with the imperative verb
"فتح" in the finding detail and in the status filter, next to state labels such
as "تم الإصلاح" and "تم تجاهلها". The filter and the detail now read the state
form, agreeing with the finding noun.
The dismiss sheet and the feature's navigation labels also named a security
finding with two different nouns: "الملاحظة" in the sheet header, its not-found
title and the findings navigation label, and "النتيجة" everywhere else,
including the same sheet's permission explanation. Every listing string now
uses the catalog's dominant noun and keeps its grammatical agreement.
Twenty-one other catalogs labelled the same two keys with an action form too:
an infinitive or imperative ("Abrir", "Openen", "Apri", "کھولیں") or a
nominalized "opening" ("Obertura", "Apertura", "Deschidere", "Отваряне"). Each
now carries that language's state adjective. Catalog and plural checks cover
every edited locale; the Arabic and Spanish states are verified on the screens
that render them.
iscekic
added
drain
|
bot: Arabic Security Agent copy, exercised on the Android emulator against the local dev stack with the app in an owned test organization (member role, one open high-severity finding seeded in local Postgres). Each pair below is the same screen and the same bundle, first with
The dismiss-sheet pair is the reported mix: the header and the not-found title used one noun while the description used the other; they now agree. The member role reaches the permission state because The Spanish read is the on-screen spot check for the twenty-one catalog edits that are not Arabic; the remaining locales are covered by Arabic was set through the Android per-app locale override (
|
|
bot: Design gate at the pull request head, Android
The same run over
Contact sheet attached; the run is uploaded for this head under the session's design-gate path.
|
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Executive SummaryThe 18 changed lines in 9 catalogs are in-place value edits that make the open-state label agree with each catalog's finding noun; commas, key order, and the two edited key paths are intact, and every edited locale already lists Assumptions: Files Reviewed (9 files)
Previous Review Summary (commit 5e66ab3)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit 5e66ab3)Status: No Issues Found | Recommendation: Merge Executive SummaryAll 22 changed catalogs contain only in-place value edits; each JSON file parses cleanly, the edited keys stay present with no key additions or removals, and the Arabic state forms agree with their sibling labels ( Assumptions: Files Reviewed (22 files)
Reviewed by deepseek-flash-latest · Input: 63.5K · Output: 15.5K · Cached: 950.9K Review guidance: REVIEW.md from base branch |
iscekic
added
the
merge:bot
The state word for the open finding status has to carry the gender of the noun that catalog already uses for a finding. Nine catalogs took the masculine dictionary form in the previous commit while their own copy for the same object is feminine or neuter: - it: "La segnalazione non è più aperta" -> Aperta - pt: "A ocorrência já não está aberta" -> Aberta - ca: "La incidència ja no està oberta" -> Oberta - ro: "Constatarea nu mai este deschisă" -> Deschisă - bg: "Проблемът вече не е отворен" -> Отворен - nb: "Funnet er ikke lenger åpent" -> Åpent - mt: "Is-sejba m'għadhiex miftuħa" -> Miftuħa - pa: "ਸਮੱਸਿਆ ਹੁਣ ਖੁੱਲ੍ਹੀ ਨਹੀਂ ਹੈ" -> ਖੁੱਲ੍ਹੀ - pt-BR states the same condition as "em aberto" throughout, so its status keeps that phrase instead of a bare adjective. Each replacement is the adjective form the catalog already uses in securityAgent.remediationUnavailable.findingNotOpen and securityAgent.dashboardMetrics.openFindings, so the label agrees with the sentence next to it.
iscekic
added
merge:blocked:kilobot-not-ready
|
bot: Correction to the state label in nine catalogs, now on the head. The state word has to carry the gender of the noun each catalog already uses for a finding, so I re-derived every replacement from that catalog's own sentences (
The first commit used the masculine dictionary form for these nine; each now agrees with the sentence beside it. Verified on screen: the Italian finding detail reads
|
|
bot: Design gate rerun at the new head: 16 cells, 15 errors, 17 warnings. The same run over main's catalogs produced the same rules on the same element paths (16 errors); the split between the dismiss-header
|
|
bot: Arabic reads at the current head, from the design gate's own Arabic RTL cell screenshots for the four changed targets (same run uploaded for this head):
So the terminology and the open-state labels hold at this head as well as at the previous one; the second commit changed the nine non-Arabic catalogs and the Italian read above covers that edit. |
|
bot: Design gate rerun after the stop check, at the same head (
Exit 2 played no part in any run here; the earlier exit-2 attempts were the
|
Evidence
Evidence: demonstrated — on the Android emulator against the local dev stack, the reported Arabic surfaces were captured before and after this branch with
uiautomatorlabel reads: the finding detail's status row and the filter'sالحالةoption readفتحonmainandمفتوحةon this branch, and the dismiss sheet's header, not-found title and permission explanation named the finding with two nouns before and one after.What changed
apps/mobile/src/i18n/locales/only: value-level edits of existing entries. No key added or removed, no English copy touched, no markup or style changed.Open finding state (Arabic).
securityAgent.findingDetails.statusOpenandsecurityAgent.filter.statusOpenwereفتح, the verbal noun/imperative, in a row of state labels (تم الإصلاح,تم تجاهلها). Both now readمفتوحة, agreeing with the finding noun and matching the catalog's existingنتائج مفتوحةandالحالة: مفتوحة.One noun per security finding (Arabic). The feature named the same object with two nouns. Nine strings used
الملاحظة:common.findingssecurityAgent.dismiss.titlesecurityAgent.dismiss.notFoundTitlesecurityAgent.dismiss.couldNotLoadsecurityAgent.dismiss.reasonInaccuratesecurityAgent.findingDetails.reasonInaccuratesecurityAgent.automation.queued,_othersecurityAgent.remediation.unavailableThe other 67 strings in the namespace already used
النتيجة/النتائج, including the same sheet's permission explanation (لا يمكن استبعاد هذه النتيجة) and the filter title (تصفية النتائج).common.findingsis the findings header the finding list renders; the code reviewer's Arabic already saysالنتائجelsewhere, so the shared label becomes consistent there too.The same state defect in the other catalogs. Twenty-one catalogs labelled these two keys with an action form: an infinitive or imperative (
Abrir,Apri,Openen,Atvērt,Opna,Åpne,Buka,کھولیں,ਖੋਲ੍ਹੋ,Ашу,Agor) or a nominalized "opening" (Obertura,Apertura,Ouverture,Deschidere,Отваряне,Hapje,Ftuħ). Each now carries the state form its own catalog already uses, taken fromsecurityAgent.remediationUnavailable.findingNotOpenandsecurityAgent.dashboardMetrics.openFindingsin that catalog, so the noun's gender agrees with the sentence beside it:El hallazgo ya no está abiertoAbiertoO achado xa non está abertoAbertoLa incidència ja no està obertaObertaLe signalement n'est plus ouvertOuvertLa segnalazione non è più apertaApertaA ocorrência já não está abertaAbertaA ocorrência não está mais em abertoEm abertoConstatarea nu mai este deschisăDeschisăПроблемът вече не е отворенОтворенGjetja nuk është më e hapurHapurKonstatējums vairs nav atvērtsAtvērtsFrávikið er ekki lengur opiðOpiðFunnet er ikke lenger åpentÅpentIs-sejba m'għadhiex miftuħaMiftuħaNid yw'r canfyddiad ar agor mwyachAgoredDe bevinding is niet meer openOpenTemuan tidak lagi berstatus terbukaTerbukaPenemuan tidak lagi terbukaTerbukaМәселе енді ашық емесАшықਸਮੱਸਿਆ ਹੁਣ ਖੁੱਲ੍ਹੀ ਨਹੀਂ ਹੈਖੁੱਲ੍ਹੀکھلاagrees with the masculine finding noun)کھلالا توجد نتائج مفتوحةمفتوحةBoth keys keep one value per catalog, and
openalready has a wording exception for each edited language, so the one-wording rule incheck:i18nstays satisfied.Observation, not exercised on screen. Arabic also used
فتحfor two other state keys with the same defect:prReview.overview.stateOpen(nowمفتوح, matching its siblingstateOpenApproved=مفتوح · …) andorganization.invoices.status.open(nowمفتوحة, matchingمدفوعة/ملغاة). Neither screen is part of this change and neither was driven here.Verification on this VM
Stack:
pnpm dev:setup-env,pnpm drizzle migrate,pnpm dev:start core mobile --no-attach,@kilocode/harness-sdkand@kilocode/trpcbuilt,pnpm dev:env:mobile --host localhost. Emulatoromp36running the CImobile-native-androiddev client built from this branch's base commit (no native file changed), Metro from this checkout, and an owned fake organization fixture in local Postgres (member role,agent_configs.platform='github', one open high-severity finding).Assertions per state, read from
uiautomatordumps of the same bundle,main's catalog against this branch's catalog:mainالخطورة: عالٍ·فتحالخطورة: عالٍ·مفتوحةالحالة(ar)فتحمفتوحةالملاحظاتالنتائجاستبعاد الملاحظة, bodyلا يمكن استبعاد هذه النتيجةاستبعاد النتيجة, bodyلا يمكن استبعاد هذه النتيجةاستبعاد الملاحظة/الملاحظة غير موجودة/ربما أُزيلت هذه النتيجة…استبعاد النتيجة/النتيجة غير موجودة/ربما أُزيلت هذه النتيجة…Gravedad: Nivel alto·AbiertoGravità Livello alto·Aperta; list headerProblemi rilevatiThe member role reaches the dismiss permission state (
canManageSecurityAgentdeniesmember), and an unknown finding id reaches the not-found state. Arabic, Spanish and Italian are read on the screens that render them; the remaining edited catalogs are covered by the catalog checks, which enforce one value per English string across a catalog.Checks:
pnpm --filter kilo-app check:i18n(oxlint i18n rules +check-catalogs),pnpm --filter kilo-app check:plurals,pnpm exec oxfmt --checkon the 22 edited catalogs.Locale switching note: Arabic is set through the Android per-app locale override (
cmd locale set-app-locales com.kilocode.kiloapp --locales ar), which is the mechanism this verification used; the app's in-app language sheet was not used for Arabic here. Spanish and Italian were switched through the app's own language sheet. Both paths feed the samei18nresolution and the same layout, and the language-sheet path itself is unchanged by this pull request.Design gate
Design gate: 16 cells, 16 errors, 20 warnings
Four matrix cells (base, dark, compact, Arabic RTL) × four targets: the finding detail, the filter sheet, the dismiss sheet as a member, and the dismiss sheet for an unknown finding id. This branch changes no markup or style at all —
apps/mobile/src/components/screen-header.tsxand every other component are untouched (git diff main...HEADcontains locale JSON only) — and the run reports exactly the errors an identical run overmain's catalogs reports on the same emulator: 16 errors in both, 14safe-areaplus 2layout-shift, on the same element paths. The only differences between the two reports areunsettledwarnings, which move between runs.Exit 1 here is therefore not fixable inside this change, and the two classes are:
safe-areaon the two dismiss targets (14):ScreenHeaderwithmodalkeeps a fixed grabber clearance because a form sheet is its own window and owns its top inset (apps/mobile/src/components/screen-header.tsx:18-25,:297-301). A gate target is only{ id, link }, so the dismiss route is opened by deep link, outside its native sheet, and the rule compares the header's box with the app window's inset instead of the sheet's. Measured on the run's own screenshots (1080×2400, 420 dpi): the status-bar clock occupies y 55–81 px and the sheet header title y 123–166 px, i.e. the header renders clear of the status bar, and the same pixels measure y 129–166 px in themainrun. Nothing collides; the number comes from the measurement window, not the screen.layout-shifton the finding-detail header paragraph (2): 7.6 dp after settling, insideScreenHeader, also present in themainrun.touch-target38.5 dp on the detail header icon (4) andunsettledroots (8 here, 4 onmain), both present onmain.Production prerequisites
None.
Proxy answers
The owner's proxy gave these answers in the owner's place.
Answer: Arabic + those 21 locales
Confidence: 0.82 · Precedent: Fix the class on every affected variant: session 8dbecc6e9e16, "I noticed the error in Serbian, but please check all languages and so fix the class"
Answer: مفتوحة
Confidence: 0.70 · Precedent: Keep similar elements consistent across surfaces: session a247f3c19b1e, thought row must match tool call row (matches existing 'نتائج مفتوحة' / 'الحالة: مفتوحة')
Answer: Fix and state as observation
Confidence: 0.60 · Precedent: Fix the class, and fix gaps even if unrelated: session 89824a222897, "if you saw a gap, fix it"; keep the PR description true to the diff: session 4bf7a5a30d91
Answer: Change common.findings
Confidence: 0.80 · Precedent: Keep similar elements consistent across surfaces, and fix the class on all surfaces: session 75f8833fe8c1, "fix this for all ... on all surfaces"