Repository navigation
Conversation
…guage tags - FHIR output shows a locale as a BCP-47 tag, pt_BR as pt-BR: designation language in CodeSystem, $lookup and $expand, and the CodeSystem and ConceptMap language (LanguageTagField, bcp47). Only the separator changes. - displayLanguage ($lookup, $expand, $validate-code) and the CodeSystem language search match a stored locale in either spelling, ignoring case (language_key). - Stored data, FHIR writes and OCL's REST output are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AaZ4qTHAarCyLb2cuys8Yd
Member
Author
|
Full suite locally at 795a169, run as CI runs it (
|
Member
Author
Codex review, pass 1 (codex-cli 0.169.0, commit 795a169)Verdict: clean. No findings. findings.json{
"reviewer": "codex-cli 0.169.0",
"perspective": "defects",
"mode": "full",
"commit": "795a169c",
"verdict": "clean",
"prior": [],
"findings": []
} |
Member
Author
Simplification review (fresh Claude subagent, commit 795a169)Verdict: findings (1 shrink).
Responses
No commits after 795a169, so no further Codex check is needed. findings.json{
"reviewer": "claude subagent",
"perspective": "simplify",
"mode": "full",
"commit": "795a169c",
"verdict": "findings",
"prior": [],
"findings": [
{
"id": "S1",
"severity": null,
"tag": "shrink",
"file": "core/common/fhir_helpers.py",
"line": 14,
"claim": "language_key repeats bcp47's falsy guard. bcp47 already returns a falsy locale unchanged, so the second `if locale else locale` only exists to avoid calling .lower() on None or ''. The same job fits in one expression.",
"scenario": null,
"action": "def language_key(locale):\n return (bcp47(locale) or '').lower() # only if callers can accept '' instead of None for a missing locale; otherwise keep as is",
"lines_delta": -1,
"confidence": "low"
}
]
} |
Member
Author
|
@snyaggarwal this is ready for review. Jon asks you to merge it if you approve; he knows you're working this weekend.
|
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
closes OpenConceptLab/ocl_issues#3031 (part of OpenConceptLab/ocl_issues#3029)
OCL stores locales such as
pt_BR, following CIEL, and FHIR output copied them unchanged. FHIR needs BCP-47 tags. FHIR output now sendspt-BR, anddisplayLanguage=pt-BRfinds a name stored aspt_BR. Stored data and OCL's REST output don't change.Independent of oclapi2#993 (OpenConceptLab/ocl_issues#3030): both change
core/code_systems/serializers.pyandcore/fhir/search.py, but the two branches merge cleanly in either order.Changes
core/common/fhir_helpers.py:bcp47(locale)swaps_for-.language_key(locale)compares languages in either spelling, ignoring case.core/common/serializers.py:LanguageTagField, aCharFieldthat shows a locale as a BCP-47 tag and writes what it's given. It's used for the CodeSystemlanguage, the CodeSystem designationlanguageand the ConceptMaplanguage.core/fhir/ops/concepts.py:designations()($lookup,$expand) sends BCP-47 tags.display_of()($lookup,$expand,$validate-code) matchesdisplayLanguagewithlanguage_key.core/fhir/search.py: the CodeSystemlanguagesearch parameter matches a default locale in either spelling, ignoring case, so searching for what the read shows finds it.Tests
$lookupand$expand(pt-BR,pt_BRandPT-brall pick thept_BRname; designations saypt-BR), the CodeSystem read (languageand designations arept-BR, while the REST source and concept still saypt_BR), the ConceptMaplanguage, and thelanguagesearch parameter.core.fhir,core.code_systemsandcore.concept_mapspass locally (804 tests). Full-suite result: see the comment below.pylint -j0 core/10.00.Decisions to confirm
eng,por) and free-text locales go out as stored. Some production sources have those as their default locale. Normalizing them belongs to OCL-wide locale handling, Locale string representation compliance ocl_issues#2795.languagechanges too. The ticket names CodeSystem, but it's the same FHIR element. OCL's ValueSet output has nolanguage.languagesearch parameter takes either spelling. Otherwise, searching for the language a read shows would find nothing.pt-BRdesignation written through FHIR is stored aspt-BR, not changed topt_BR. Choosing one stored spelling belongs to Locale string representation compliance ocl_issues#2795.displayLanguage=ptdoesn't pick apt_BRname, as before.🤖 Generated with Claude Code
https://claude.ai/code/session_01AaZ4qTHAarCyLb2cuys8Yd