[whoalin1]

Summary

#2399 asked for separate Transifex strings for the “New contact” button vs the name field default. Main already uses New contact on the button and Name as the FN default / input label.

missingFN.js still compared against New contact, so the “don’t auto-fix an untouched new-contact FN” branch never ran for contacts created with the Name default.

Align the check with t('contacts', 'Name').

Closes #2399

Test plan

• New contact → leave Name as default → save with other fields: missingFN does not overwrite FN from empty N
• Existing contact whose FN was left as the default Name and that has structured N: repair still builds FN from N
• Button label remains “New contact”

---

AI disclosure

This PR was drafted with the help of AI coding assistants (Cursor agents / LLM-based tools), including the description. I am responsible for it and happy to rework anything that doesn't fit.

All commits carry an Assisted-by: Cursor:grok-4.7 trailer.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[hamza221]

Looks good, thank you for the fix, could you please update the commit message.
It's not a l10n fix, and then I will approve and merge

[hamza221]

/backport to stable8.9

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

[hamza221]

/backport to stable8.9

[whoalin1]

Looked into the failing static-psalm-analysis jobs (dev-master, dev-stable33/34/35) on this PR.

Root cause is unrelated to this PR's change (this PR only touches src/services/checks/missingFN.js): the composer require --dev roave/security-advisories:dev-latest step fails to resolve because the runner's PHP (8.1) conflicts with roave/security-advisories's current advisory constraints (php <8.2.35|>=8.3,<8.3.36|>=8.4,<8.4.27|>=8.5,<8.5.12):

Problem 1
  - php is present at version 8.1 and cannot be modified by Composer
  - Root composer.json requires roave/security-advisories dev-latest -> satisfiable by roave/security-advisories[dev-latest].
  - roave/security-advisories dev-latest conflicts with php <8.2.35|>=8.3,<8.3.36|>=8.4,<8.4.27|>=8.5,<8.5.12.

This run is from 2026-10-22. The same Static analysis workflow has been passing on other PRs in this repo since 2026-10-23, so this looks like a transient advisory/runner mismatch that has since cleared upstream rather than something fixable from this branch. I don't have maintainer/admin rights on this repo to re-run the job myself (gh run rerun was refused with "Must have admin rights to Repository"), so flagging here in case a maintainer can re-run the static-psalm-analysis checks — I'd expect them to go green without any code change, since all other checks (lint, build, e2e, php-cs, etc.) already pass and the PR has been approved.

No code changes pushed, since there's nothing in this PR's diff to fix for this failure.