Logic for missing localization key and tables

[bestwnh]

For the current version(3.0-alpha.8), if the view use some LocalizedKeyString but can't find the value for it, the whole page break with error missingKeys or missingTables.

I thought a string missing should not break the whole page. So I suggest if the localized key is missing for current locale, first use the value for default locale, if still missing fallback to the key value that set in the View. If possible, output the error in the browser console. That can help developer find out the missing translation but also provide a functional page even the developer missing some translation string.

Localization is good, but functional page should be more important.

[mattesmohr]

I think, you might be right.

Let me think about it a bit more.

[nicktrienensfuzz]

Is there a way to turn off all Localizations?

If don't need this feature can i stop this throw?

        guard let localization = self.localization else {
            throw Errors.missingLocalization
        }

[mattesmohr]

Is there a way to turn off all Localizations?

If don't need this feature can i stop this throw?

You don't have to use the localization at all.

It will only be triggered if you use an Element which returns an LocalizedStringKey.

Is that what happened here or why do you want to opt it out entirely?

[bestwnh]

@mattesmohr I think the problem is people don't think this two way to build the view would make so much different

Heading1 {
    "Hello World"
}

and

Heading1("Hello World")

People couldn't tell any localize related info from the api.

And also if from day one I don't need localization, but later I may need to add it. I need to change all those apis but not just add the missing language table and keys.

[mattesmohr]

It is true, I see where the confusion is coming from. And I also see your point. I like the idea of having one initializer for all cases.

But at the same time. I like how straight forward the API is, right now. And not only for the paragraph elements, but for all elements.

/// Heading1 is a content element and expects content, therefore we have a closure
Heading1 {
   "Hello World"
}
/// Just like <h1></h1> where a closing tag is needed

/// Image is an empty element with no content, so no closure is needed
Image()
/// Exactly like <img>

If we start changing the API, I foresee endless discussions about initializers for each element, which is something I'd prefer to avoid.

Also, when dealing with a long text, the second one seems much more cleaner.

Heading1("Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor 
invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.  At vero eos et accusam et justo duo 
dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. 
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut 
labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo 
dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.") 


Heading1 {
   """
   Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt 
   ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo 
   dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. 
   Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt 
   ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo 
   dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum
   dolor sit amet.
   """
}

Sooo...

One option is to leave the localization entirely up to the user, by removing the current initializer and requiring them to use:

Heading1 {
   LocalizedKeyString(key: "label.manager")
}

Or. We can make it more explicit, by naming the argument.

Heading1(localizedKey: "label.manager")

But to be honest, I like it as it is right now. I think the confusion is more about the lack of documentation, examples and communication, which is on me. Maybe we need a Discord Server, where we can go more into the discussion.

Also I am very sorry, that your issue is open for far too long. I spend too much of summer with my family, I guess.