[wp-trac] [WordPress Trac] #63974: .mo file loaded as UTF-8 by default - non-standard and ignoring Content-Type headers

[WordPress Trac]

#63974: .mo file loaded as UTF-8 by default - non-standard and ignoring Content-
Type headers
--------------------------+------------------------------
 Reporter:  kkmuffme      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  I18N          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by kkmuffme):

 >are any of them saving files not as UTF-8?

 What do you mean? A file does not have an inherent encoding, which is why
 the "Content-Type" header should be used.

 >what's the downside of being a bit less strict?

 One (and the biggest pain point for me) is that .mo files aren't valid and
 can't be converted back to .po files with basic msgunfmt tool (since all
 UTF-8 will get stripped).

 >If your suggestion is to reject any MO files with Content-Type other than
 UTF-8, then I'd classify this ticket as an enhancement.

 The suggestion is:
 - if no Content-Type header with charset=UTF-8 is provided, treat the file
 as ANSI (= remove all multibyte)
 - if Content-Type header with charset=UTF-8 is provided, no change
 - any other charset= provided, add a doing_it_wrong that WP does not
 currently support this charset, and will instead treat this file as UTF-8

 This change won't affect most sites at all and for those plugins that are
 affected (= they provide .mo files with  the Content-Type header missing)
 it's a minimal, simple fix in their release pipeline which ensures that
 their .mo files adhere to the standard more exactly and prevent encoding
 issues.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63974#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform