`useLingui` should be "React friendly"

Is your feature request related to a problem? Please describe. I want to have elements I could use anywhere in my code, so I do thing = <Trans>Hello</Trans>, however sometimes I have to pass this as a string to placeholders and other things. I could use Trans.render to “renderProp” the message, but I would prefer useLingui._ to translate what I have into the string. Unfortunately that is returning [Object object]

Right now API exposed thought i18n is friendly only to core, not react. Well, it is from core.

Describe the solution you’d like i18n._ from useLingui or I18n should understand that some values might be a React.Elements.

Describe alternatives you’ve considered Well, all I need is stored in the Trans`s props.

if (id.type === Trans) {
   return i18n._(id.props);
}

Additional context Technically, implementation of Trans should be exposed to the end user, so one could call it without using Trans itself.

[tricoder42]

In v3 all js macros return translation, not an object:

t`GitHub` === 'GitHub'
// t`GitHub` is the same as i18n._({ id: `GitHub` })

I guess that solves your problem?

So I am changing my code to const ProductName = <Trans>GitHub</Trans>.

Why don’t you use i18n._ here?

const ProductName = i18._(t`GitHub`) // This is the same as t`GitHub` in v3

[khmm12]

Not sure what we could do here. React components can read i18n from context, there’s no such mechanism for pure js objects. Is there a global object which is specific to current request? Then you could create a simple wrapper, like:

There is no problem to provide instance. The problem is that all macros except defineMessage use imported global instance.

Assume we have async safe getI18n which returns right i18n instance. It can be done with Continuation Local Storage.

v2

function getMessage() {
  const i18n = getI18n()
  const title = i18n._(t`Greetings`)
}

—transformed—>

function getMessage() {
  const i18n = getI18n()
  const title = i18n._({ id: 'Greetings' })
}

v3

function getMessage() {
  const title = t`Greetings`
}

—transformed—>

import { i18n } from '@lingui/core'

function getMessage() {
  const title = i18n._({ id: 'Greetings' })
}

getI18n?

function getMessage() {
  const i18n = getI18n() /* Looks like unused variable? */
  const title = t`Greetings`
}

—>

import { i18n } from '@lingui/core'

function getMessage() {
  const i18n = getI18n()
  const title = i18n._({ id: 'Greetings' })
}

Shallow variable declaration may work, but doesn’t play well with static analysis tools, because before transformation the variable isn’t used anywhere.

React components can read i18n from context

With new macros you meet the same issue as above. You consume i18n from context, but don’t use in explicit way.

v3

function Signin() {
const { i18n }  = useLingui() /* Looks like unused variable */

return (
  <form>
    <input type="email" placeholder={t`Your email`} />
    <button type="submit">
      <Trans>Sign in</Trans>
    </button>
  </form>
)
}

v2 like

function Signin() {
  const { i18n }  = useLingui() /* The variable is used bellow */

  return (
    <form>
      <input type="email" placeholder={i18n._(t`Your email`)} />
      <button type="submit">
        <Trans>Sign in</Trans>
      </button>
    </form>
  )
}

It does and I don’t think it’s a big deal. This isn’t a process that user does often and repeatedly. When user visits the page, locale-detector kicks in and selects the appropriate locale. When it fails, user switches the locale and it’ll be picked by next time by locale-detector. So, it only happens when 1) locale-detector isn’t successful 2) user sets the locale for the first time

it leaves no choice. For some existing applications migration to v3 becomes impossible, because you either loose ability to change language without loosing application state or have issues with stuck messages.