[v4] Language editor doesn't support keys with spaces

[mrflix]

I just looked at the language editor for the first time. Beautiful work!
I created some variables in languages/de.php and then explored them there. Turn's out that the UI breaks when the key contains a space. This is the error I see when clicking on Jetzt anmelden!:

Capitalized keys also "wrongly" get lowercased:

I didn't run in problems yet when using the primary-language value as the key in translations.
I think it's nice that they're very verbose opposed to generic terms like signup.button. Those make a lot of sense in big projects but I don't see their need in small projects.

Version: alpha.3

[distantnative]

Not quite a bug, but intended to be that way. One can probably argue if it should be different. But supporting more characters isn't 100% trivial as the key itself is used in the request endpoint string.

[lukasbestle]

Could we percent-encode it in the URL?

[afbora]

I think we can allow all characters 0-9A-Za-z\-\_\. that can be used in the key. For ex: error.loginForm-success_text

This could be all the characters that PHP array() allows.

The key can either be an int or a string. The value can be of any type.

Additionally the following key casts will occur:

• Strings containing valid decimal ints, unless the number is preceded by a + sign, will be cast to the int type. E.g. the key "8" will actually be stored under 8. On the other hand "08" will not be cast, as it isn't a valid decimal integer.
• Floats are also cast to ints, which means that the fractional part will be truncated. E.g. the key 8.7 will actually be stored under 8.
• Bools are cast to ints, too, i.e. the key true will actually be stored under 1 and the key false under 0.
• Null will be cast to the empty string, i.e. the key null will actually be stored under "".
• Arrays and objects can not be used as keys. Doing so will result in a warning: Illegal offset type.

[lukasbestle]

@afbora TBH I don't quite understand how arrays play into this. A space would also be a valid character in an array key.

[afbora]

Can't we manage the translations array in the language files in the panel without any intervention (no lowered, no uppered, just allow defined chars something like that 0-9A-Za-z\-\_\.)? I don't know if anyone uses spaces in the arrays, but I think we support at least the basic characters, it will be enough.

<?php

return [
    'code' => 'en',
    'default' => true,
    'direction' => 'ltr',
    'locale' => [
        'LC_ALL' => 'en_US'
    ],
    'name' => 'EN',
    'translations' => [
        'foo bar' => 'Hello',
        'foo_bar' => 'Hello',
        'foo.bar' => 'Hello',
        'foo-bar' => 'Hello',
        'fooBar' => 'Hello',
    ],
    'url' => NULL
];

[lukasbestle]

Well, the author of this issue does, or at least wants to. 😄

I think it would be totally fine to use your suggestion as a first step though if support for all characters (using percent encoding in the URL) is not possible or too much work.

[mrflix]

One reason for reporting this is that it might break this view after upgrading to v4. Since there were no restrictions so far on how to pick language variable key value pairs.

I just did a reality check with websites that I built: out of 14 websites that use language variables, 3 contain spaces and capitalized words and in their keys. One of those three projects is in development, one is live and one is obsolete. So it doesn't affect a lot of my clients.