How to insert a line break?

[FezVrasta]

Hi, I can't seem to find any way to insert a line break (either a <br /> or a \n).

The only option I can think of is to use the string formatting with:

test: 'some very very long string.{0}I want to break it on multiple lines',

[...]

strings.formatString(strings.test, <br />)

But it's not a great solution since I will need to remember to use this syntax every time I want to use that string.

May you help me please?

[stefalda]

Can you show me an example of your use case?

[FezVrasta]

I have a long sentence and I want to specify some line breaks to make the reading easier.

I think it’s a reasonable request

[evlist]

@FezVrasta you're not limited to strings and you can include HTML fragments and React components.

Your file will need to be a .jsx (or tsx) and you'll be able to define things such as:

test: <Fragment>some very very long string.<br/>I want to break it on multiple lines</Fragment>

[FezVrasta]

Thanks, I don't think this is mentioned anywhere in the documentation right?

[evlist]

That's not in the documentation but it's mentioned in issue (#115), however, doing more tests it seems to be working fine with Chrome but not with Firefox where is raises the following error:

or, in plain text:

Uncaught TypeError: "key" is read-only
    _fallbackValues LocalizedStrings.js:191
    _fallbackValues LocalizedStrings.js:189
    _fallbackValues LocalizedStrings.js:197
    _fallbackValues LocalizedStrings.js:189
    setLanguage LocalizedStrings.js:173
    setContent LocalizedStrings.js:99
    LocalizedStrings LocalizedStrings.js:69

LocalizedStrings.js:191 is

          strings[key] = defaultStrings[key]; // eslint-disable-line no-param-reassign

Interestingly, eslint has been disabled on the line which raises the error in Firefox !

[evlist]

In fact that doesn't work with Chrome either (the only reason it didn't raise the error was because it was set with th edefault language while Firefox was not).

The issue is that when building the fallback values, the library recursively copies properties in objects (probably to support using plain JS objects to give some structure to the localization objects), it doesn't differentiate JS object literals from more complex objects such as React components and recursively copying these object properties just doesn't work.

I guess a fix would be to add a test to differentiate "simple" from "complex" objects.

[evlist]

There doesn't seem to be a way to differentiate between simple and complex objects in JavaScript, however, React components have a $$typeof property which will likely not appear on "simple" objects.

A quick and dirty way to fix the problem is to apply this patch:

diff --git a/node_modules/localized-strings/lib/LocalizedStrings.js b/node_modules/localized-strings/lib/LocalizedStrings.js
index eefa6c8..e0a3cae 100644
--- a/node_modules/localized-strings/lib/LocalizedStrings.js
+++ b/node_modules/localized-strings/lib/LocalizedStrings.js
@@ -192,8 +192,8 @@ var LocalizedStrings = function () {
           if (_this4._opts.logsEnabled) {
             console.log("\uD83D\uDEA7 \uD83D\uDC77 key '" + key + "' not found in localizedStrings for language " + _this4._language + " \uD83D\uDEA7");
           }
-        } else if (typeof strings[key] !== "string") {
-          // It's an object
+        } else if (typeof strings[key] !== "string" && defaultStrings[key].$$typeof === undefined) {
+          // It's an object (and it's not a React component)
           _this4._fallbackValues(defaultStrings[key], strings[key]);
         }
       });

However, this patch is on the LocalizedStrings which aims to be generic and will perhaps not be interested by a fix which is React specific!

[evlist]

I have open an issue in localized-strings.