OK. Thanks. My understanding it that this should work just fine for a single call to render(), but you're then mutating the DOM outside of React, so the next time render() is called React will overwrite your localized strings with the unlocalized ones.
Joe. On Fri, Apr 8, 2016 at 2:39 PM Axel Hecht <[email protected]> wrote: > On 08/04/16 15:18, Joe Walker wrote: > > Axel Hecht wrote: > > > >> ... > >>> Right, obviously. But that seems like a small cost compared with the > >>> massive cost (both to development and to live usage) of making every > >> string > >>> lookup asynchronous. > >> We actually have a rich experience from converting gaia apps and their > >> developers to these APIs, and it turned out that once you get into it, > >> things are much nicer. A lot of the gaia devs were much happier to use > >> the l20n apis compared to the old sync l10n.js ones. > >> > >> The key here is to use the API in the ways it's strong: > >> > >> Just add html, and let the library localize it. This is what the > >> experiment that stas did around "just use l20n" did. Just pass the data > >> to the html, and the l20n library will figure out what to do, and when. > >> > >> That's a lot easier than manually looking up each string, and then > >> marshalling it through a bunch of DOM calls. > >> > > So the render() call in React is synchronous. There is no option to > resolve > > a promise. > > The only thing you can do is to some form of re-render at a later time. > > > > The examples seem to mostly cause a re-render by calling setState one way > > or another when the string is available. > > The trouble is this doesn't address the lifecycle of a react application. > > When something else changes, and you need to re-render for a different > > reason, you need to start all over again with an async lookup ... > > > > Presumably, string formatting is synchronous with l20n? I think that's > the > > place to start looking. Could you give me a pointer to a format function? > > > > Thanks, > > Joe. > I suggest to look at > https://github.com/mozilla/activity-streams/pull/429/files. > > I'm afraid that somewhere in this thread, we lost you on one of the > tangents we took. Seems we lost you on one that we don't like either. > > What stas did on activity stream, and on > https://github.com/stasm/l20n-react-experiments/tree/gh-pages/mutation > with just using l20n and data-l10n-id on the react/virtualdom side is > effective, and pretty straight forward for devs and tools. > > Axel > > > _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
