Closed Bug 1900765 Opened 1 year ago Closed 1 year ago

Trailing whitespace should not be trimmed from values in .properties files

Categories

(Core :: Internationalization, defect, P3)

defect

Tracking

()

RESOLVED FIXED
129 Branch
Tracking Status
firefox128 --- wontfix
firefox129 --- fixed

People

(Reporter: eemeli, Assigned: eemeli)

References

Details

Attachments

(1 file)

Since at least Firebird 0.6, we've been trimming the trailing spaces and tabs from .properties values, which is different from how the java.util.properties implementations parse the files:

Any white space after the key is skipped; if the first non-white space character after the key is '=' or ':', then it is ignored and any white space characters after it are also skipped. All remaining characters on the line become part of the associated element string; if there are no remaining characters, the element is the empty string "".

By now, we no longer have any source values which include trailing whitespace, but we do have 1096 localized strings that include trailing spaces, most because they were translated from an earlier en-US source that included a trailing space.

In Pontoon, trailing whitespace in .properties values is treated as a warning, just as empty values are.

We should fix all of the localized strings (much easier once bug 1877097 lands) and stop trimming the values.

The trailing spaces were fixed in localized strings in mozilla-l10n/firefox-l10n#9.

Assignee: nobody → earo
Attachment #9405656 - Attachment description: WIP: Bug 1900765 - Stop trimming trailing whitespace from .properties values → Bug 1900765 - Stop trimming trailing whitespace from .properties values. r?#xpcom-reviewers!
Status: NEW → ASSIGNED
Pushed by earo@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4132a83fedbd Stop trimming trailing whitespace from .properties values. r=xpcom-reviewers,nika
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 129 Branch

Would there be any value from a long-term maintainability standpoint to taking this on ESR128?

Flags: needinfo?(earo)

No need for an ESR uplift. Any patch releases will end up picking up the trimmed strings for their localizations, and there's no harm in attempting to trim them during formatting.

Flags: needinfo?(earo)
See Also: → 1907026
See Also: → 1907027
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: