I am late to the discussion, but I use this react-mixin for my l20n
components
npm install --save react-mixin@2
import ReactDOM from 'react-dom';
export default {
componentDidMount() {
document.l10n.translateFragment(ReactDOM.findDOMNode(this));
}
componentDidUpdate() {
document.l10n.translateFragment(ReactDOM.findDOMNode(this));
}
}
Keep it simple, stupid.
--
Matej
On Fri, Apr 8, 2016 at 5:31 PM, Axel Hecht <[email protected]> wrote:
> On 08/04/16 16:17, Joe Walker wrote:
>
>> 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.
>>
> Interesting question, I'll defer that to stas. He'll be back next week.
>
> Axel
>
>>
>> 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
>
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
