Fix PHP 8.5 deprecation: normalize locale before using as array key in Currency

[ajmalbuffy]

Problem

When executing currency resolution in Magento, PHP 8.5 emits a deprecation warning:
Deprecated: Using null as an array offset is deprecated.

The issue originates from Magento\Framework\Locale\Currency::getCurrency() where
getLocale() result was used directly as an array key without being normalized to a string first.

Fix

Extract locale into a $locale variable, normalized to a string at the top of the method
and reuse it consistently throughout, replacing all 4 direct getLocale() calls.

Testing

Verified deprecation warning appears before fix and disappears after fix on PHP 8.5.6

Fixes #40814

Description (*)

On PHP 8.5, a deprecation warning is triggered in Magento\Framework\Locale\Currency::getCurrency()
because the return value of getLocale() was used directly as an array key without being normalized
to a string first. PHP 8.5 deprecates using null as an array offset.

The fix extracts the locale into a $locale variable, normalized to string using (string) cast
with a null coalescing fallback, and reuses it consistently throughout the method, replacing all
direct getLocale() calls.

Related Pull Requests

None

Fixed Issues (if relevant)

1. Fixes PHP 8.5 deprecation warning: null locale used as array key in Magento\Framework\Locale\Currency #40814

Manual testing scenarios (*)

1. Set up Magento Open Source 2.4.9 with PHP 8.5
2. Run any operation that triggers currency formatting, e.g., getCurrency('USD').
3. Observe PHP 8.5 deprecation warning: Deprecated: Using null as an array offset is deprecated.
4. Apply the fix by extracting $locale = (string) ($this->_localeResolver->getLocale() ?? '');
5. Rerun the same operation and confirm no deprecation warning is emitted

Questions or comments

This fix also improves performance slightly by resolving the locale once per method call
instead of calling getLocale() multiple times.

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• README.md files for modified modules are updated and included in the pull request if any
• All automated tests passed successfully (all builds are green)

[m2-assistant]

Hi @ajmalbuffy. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.
❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

[engcom-Bravo]

Thank you for your contribution! The Magento core engineering team is working on the issue which you have addressed in this PR. Team will cherry pick the commits from your PR and may do further implementation to cover few more scenarios as needed. We will reach out to you if we need more information. For now, you can pause work on this PR. Thank you once again!