1 048 576 octets : voilà ce que voit un visiteur du panneau d’administration si un développeur affiche une taille de fichier brute, sans formatage. Personne ne lit un tel nombre confortablement, alors que la donnée elle-même est simple : un fichier d’un mégaoctet.
WordPress fournit deux fonctions natives pour ce genre de situation, et elles sont trop souvent ignorées au profit d’un round() approximatif ou d’un number_format() PHP standard qui, par défaut, utilise la virgule et le point à l’anglaise plutôt que les conventions françaises.
size_format : des octets à une unité lisible
size_format( int|float $bytes, int $decimals = 0 ) convertit une taille en octets vers l’unité la plus adaptée — Ko, Mo, Go, To — en choisissant automatiquement le bon multiple. Elle est utilisée dans l’administration pour afficher le poids des pièces jointes de la médiathèque, et rien n’empêche de la réutiliser dans une extension personnalisée.
function catalogue_afficher_poids_fichier( $chemin_fichier ) {
if ( ! file_exists( $chemin_fichier ) ) {
return '';
}
$poids_octets = filesize( $chemin_fichier );
return size_format( $poids_octets, 1 );
}
Avec un fichier d’environ 2,3 mégaoctets, cette fonction renverra directement une chaîne du type « 2,3 Mo » (le séparateur décimal suit la langue du site), sans qu’il soit nécessaire d’écrire soi-même la logique de conversion entre unités.
number_format_i18n : des séparateurs qui suivent la langue du site
number_format_i18n( float $number, int $decimals = 0 ) résout un problème différent mais tout aussi fréquent : afficher un nombre — un total de commandes, un compteur de vues, un nombre d’inscrits — avec les séparateurs de milliers et de décimales attendus par la langue active du site, plutôt que ceux, par défaut anglo-saxons, de la fonction PHP number_format().
Pour un site en français, un compteur de 12 458 vues s’affichera avec une espace comme séparateur de milliers, conformément aux conventions typographiques françaises, sans qu’il soit nécessaire de coder cette règle à la main :
function stats_afficher_compteur_vues( $post_id ) {
$vues = (int) get_post_meta( $post_id, '_compteur_vues', true );
return sprintf(
/* translators: %s : nombre de vues formaté */
esc_html__( '%s vues au total', 'stats-editoriales' ),
number_format_i18n( $vues )
);
}
Un tableau de bord qui mélange les deux
Dans un tableau d’administration listant des exports générés par une extension de facturation, il est courant d’avoir besoin des deux informations côte à côte : combien de lignes contient l’export, et quel est son poids sur le disque.
- Le nombre de lignes se formate avec
number_format_i18n(), pour un rendu cohérent avec le reste de l’administration. - Le poids du fichier généré se formate avec
size_format(), avec une décimale pour rester précis sans être verbeux. - Les deux fonctions acceptent un entier comme un flottant en entrée, ce qui évite un cast manuel avant l’appel.
Pourquoi éviter un formatage manuel
Écrire sa propre logique de conversion d’octets en Ko/Mo/Go paraît trivial au premier abord — diviser par 1024 plusieurs fois — mais le code fini presque toujours par accumuler des cas particuliers : que faire d’une taille nulle, d’une taille négative renvoyée par une API externe, d’un nombre de décimales qui varie selon l’unité choisie. size_format() gère déjà tous ces cas, avec un comportement testé et stable depuis de nombreuses versions du cœur.
De même, reconstruire un séparateur de milliers à la française avec des expressions régulières est un classique des bugs discrets : la locale WordPress gère cette règle correctement, y compris pour les langues où les conventions diffèrent du français, ce qui rend le site cohérent quel que soit l’utilisateur qui le consulte dans sa propre langue d’administration.
En résumé
Ces deux fonctions ont un point commun : elles évitent d’écrire un formatage manuel qui semble simple mais cache des cas particuliers coûteux à corriger plus tard. size_format() pour un poids de fichier, number_format_i18n() pour un nombre à afficher dans l’interface : les deux suivent la langue active du site et produisent un rendu cohérent avec le reste de l’administration, sans qu’il soit nécessaire de maintenir sa propre logique de conversion.
