Panel Creates Languages with Odd Locale Array

[neildaniels]

Describe the bug
I'm testing out multi-language features of Kirby, but noticed that the Panel creates odd locale arrays in the language files it generates. For example:

<?php

return [
    'code' => 'en',
    'default' => true,
    'direction' => 'ltr',
    'locale' => [
        6 => 'en'
    ],
    'name' => 'English (United States)',
    'translations' => [

    ],
    'url' => NULL
];

To Reproduce
Steps to reproduce the behavior:

1. Enable 'languages' => true in config.php
2. Create one or more languages in the Panel
3. Inspect the languages files in site/languages

Expected behavior
The locale value should either be a simple string

  'locale' => 'en',

or an array such as

  'locale'  => [
    LC_ALL => 'en',
  ],

Source: https://getkirby.com/docs/guide/languages/introduction

Kirby Version
3.3.3

Desktop (please complete the following information):

• OS: macOS
• Browser: Safari
• Version: 13.0.5 (15608.5.11)

[afbora]

Actually I can't see a problem. They are PHP's defined numbers in core:

define ('LC_CTYPE', 0);
define ('LC_NUMERIC', 1);
define ('LC_TIME', 2);
define ('LC_COLLATE', 3);
define ('LC_MONETARY', 4);
define ('LC_ALL', 6);
define ('LC_MESSAGES', 5);

@lukasbestle What do you think about that?

[neildaniels]

Ah, that makes sense. Would be nice if it could export out the constant name, instead of the value.

The underlying values could change in a future PHP version, right? Having the constant used would ensure nothing gets mangled because of that.

[neildaniels]

It could also save it as a simple string, which avoids all ambiguity.

  'locale' => 'en',

[lukasbestle]

This is something I'd like to improve as well, but it's unfortunately not possible:

The language files are stored using the Kirby\Data\PHP class. By the time that class gets the structured data from the Language class, it cannot differentiate between the constant and a simple integer (PHP internally stores constant values as the actual values, not as the constant). So exporting the constant name won't work.

The idea to save the locale as a simple string could work, but it's going to make the code quite a bit more complex (more edge-cases). Also it won't fix this issue completely as the array structure is still required if the developer has defined multiple different locales.

I'm leaving this issue open for now, but I don't think we'll implement this in the near future.

[lukasbestle]

As @bnomei ran into an actual issue that is caused by this just today, I looked into this again and found a solution that actually works quite well: #2435

[bastianallgeier]

✅