FANDOM


  • Hey guys,

    would it be an asset if we use i18next.com to standardize i18n implementation?

    Zuri

      Loading editor
    • A lightweight, standard way for i18n would be a good thing. I'm not sure i18next is it. Also, Wikia will never delegate any part of their infrastructure to a site not under their control.

        Loading editor
    • Hmmm... So the best way would be to develop an extension for this case?

        Loading editor
    • There's the I18n-js library, I guess. I use it for several scripts of mine and it's pretty good.

        Loading editor
    • KockaAdmiralac wrote: There's the I18n-js library, I guess. I use it for several script of mine and it's pretty good.

      The downside of i18n-js is that it requires an extra two network connections before the script using it can be ready… not so good for those on slow connections.

        Loading editor
    • @KockaAdmiralac: The script is still in beta. Is it already stable enough to be used?

      @OneTwoThreeFall: Maybe you could suggest some improvements to the author of the script.

      Wouldn't it be more practical to load the translation client side?

        Loading editor
    • From my experience, the script is stable enough to be used.

        Loading editor
    • Okay, fine. But If I load an i18n.json like so

      mw.hook('dev.i18n').add(function (i18n) {
          i18n.loadMessages('i18n').done(function (i18n) {
              console.log(i18n);
          });
      });

      I'm getting an error:

      Uncaught SyntaxError: Unexpected end of JSON input

      That may be caused by the leading "//" in every i18n.json file...

        Loading editor
    • No, it happens because there's no MediaWiki:Custom-i18n/i18n.json page on Dev Wiki, so it loads an empty string.

        Loading editor
    • Ah, okay, the first "i18n" has to be uppercase :D

        Loading editor
    • Agent Zuri wrote:
      @OneTwoThreeFall: Maybe you could suggest some improvements to the author of the script.

      Oh, it's not really a problem with i18n-js (on the contrary, it's quite well written!), it's just the way loading from a separate page like that has to work.

      Apart from having translations inline with the script (as most currently do), something like i18n-js is likely the most efficient way to handle this within the current infrastructure. One possible improvement, though, would be for it to cache the i18n content in browser storage, avoiding the need to fetch it with every page load.

        Loading editor
    • Okay, then this would be a possible suggestion.

      But what if it would be loaded server side?

        Loading editor
    • OneTwoThreeFall wrote: One possible improvement, though, would be for it to cache the i18n content in browser storage, avoiding the need to fetch it with every page load.
      How would it know when to update that i18n data?
      Agent Zuri wrote: But what if it would be loaded server side?
      How do you mean? We can't really modify Wikia's codebase just so it can handle i18n of Dev scripts better.
        Loading editor
    • KockaAdmiralac wrote:
      OneTwoThreeFall wrote: One possible improvement, though, would be for it to cache the i18n content in browser storage, avoiding the need to fetch it with every page load.
      How would it know when to update that i18n data?

      There could be a main object storing a mapping to the i18n files and their versions. If a file is modified, you simply have to update the version. The version can be compared with the one stored in local storage.

      KockaAdmiralac wrote:
      Agent Zuri wrote: But what if it would be loaded server side?
      How do you mean? We can't really modify Wikia's codebase just so it can handle i18n of Dev scripts better.

      I thought of an extension.

        Loading editor
    • KockaAdmiralac wrote:

      OneTwoThreeFall wrote: One possible improvement, though, would be for it to cache the i18n content in browser storage, avoiding the need to fetch it with every page load.
      How would it know when to update that i18n data?

      It wouldn't. A timestamp of when it was fetched could be kept, and if the cache is older than a few days or so, it should be ignored (few day old translations don't seem too much of an issue).

      In the case of script updates requiring new strings, the script could also have a timestamp set in its code, so older cached strings are never used for a newer script version.

        Loading editor
    • Cqm

      @OneTwoThreeFall Granted, the extra requests are not an ideal situation, but I question whether quibbling over two requests is all that worthwhile in the grand scheme of things when the average user has dozens of HTTP requests added by advertising. 2 more is a raindrop in an ocean.

      Caching would be a nice-to-have, but making it fixed is likely to cause weird issues down the line, especially if you add a new message the script now relies on and the script's cache updates before the messages do. Adding a timestamp parameter to the script seems like an unnecessary burden for an author when it's meant to be as pain-free as possible. For the time being, I don't think it is a particularly pressing issue.

        Loading editor
    • Agreed, it's not a pressing issue (especially considering the number of requests made by ads/tracking code, like you mention) - just spitballing possible improvements. :)

        Loading editor
    • A FANDOM user
        Loading editor
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.