[CLOSED] Locale don't load about bootstrap3-wysiwyg

[Waxolunist]

Comment by Waxolunist
Tuesday Dec 17, 2013 at 10:28 GMT

---

How are you initializing it? It works for me. The order of the locale script shouldn't matter. But I would suggest to load it after the editor script. Afterwards you have to set the locale to the full qualified language name. Only exception is english, where I have assigned en to en-US, because it has been in the old one en, thus no code is breaking.

<script src="components/jquery/jquery.min.js"></script>
<script src="components/bootstrap/dist/js/bootstrap.min.js"></script>
<script src="dist/bootstrap3-wysihtml5.all.min.js"></script>
<script src="dist/locales/bootstrap-wysihtml5.de-DE.js"></script>

<script>
  $('.textarea').wysihtml5({
    locale: 'de-DE'
  });
</script>

[Waxolunist]

Comment by Waxolunist
Tuesday Dec 17, 2013 at 10:31 GMT

---

Which locales are u using? Not all of them are fully translated. I will update those u request.

[Waxolunist]

Comment by Garito
Tuesday Dec 17, 2013 at 15:20 GMT

---

Oh, man!
My mistake, I don't load the script Sorry!

But... isn't it redundant?

What do you prefer? Set the locale property or load the script?

If you prefer 1st I'm not going to load the script but the library so I tell it
If you prefer 2nd the editor has to detect the script loaded and react as logical
But, in order to make the library better a decission seems mandatory

What do you think?

[Waxolunist]

Comment by Waxolunist
Tuesday Dec 17, 2013 at 15:27 GMT

---

No it isn't redundant. If you have multiple languages available, you have to load all languages you offer and load then the editor with the locale. Only in the case of having only one language it is redundant.
Automatic script loading is not as easy as it seems at first sight. Especially when it comes to amd and supporting different amd implementations. I like being explicit, because it eases minification in production.
In the other case, loading the script and take one, is difficult in the decision phase, because it is undecided what to do in the case, when multiple languages are available.

[Waxolunist]

Comment by Garito
Tuesday Dec 17, 2013 at 15:35 GMT

---

It is
If you load some locales the 1st one could be the active one
Don't care how the code choose but that provides a way to decide (even when it's so easy to achieve if you decide to load the scripts -what I hope-)

[Waxolunist]

Comment by Garito
Tuesday Dec 17, 2013 at 15:52 GMT

---

Another super small but nice optimization are the names of the locale files and value for the property

Instead of es-ES or fr-FR why don't use es_ES and fr_FR since is the same substring as the browser uses

Perhaps this are not important things for you right now but, when the code do its job, this makes the difference... (and you see that every second of your iteration with your computer if you use a mac even if you hate their pedantry as much as I do)

[Waxolunist]

Comment by Waxolunist
Tuesday Dec 17, 2013 at 16:02 GMT

---

English will always be loaded and the first one, because it is compiled into the package. It should be the fallback, what didn't work btw. I'll open an issue on that. Only using the first one is a problem, when it comes to loading multiple languages, because u never know, which one is the first loaded.
Automatic script loading is difficult and opens a load of other problems, starting with assuming a path and not playing nice with amd loaders, minifiers, etc. Maybe I can make it an option. I will have a look into that.

[Waxolunist]

Comment by Waxolunist
Tuesday Dec 17, 2013 at 16:19 GMT

---

You can open an issue for renaming the locale files. They are the way I have forked them and I have some concerns about breaking functionality for others, who are using l10n already. What I can offer is to map es-ES to es_ES in the locale option of the editor.