I suspect you may need to run mix gettext.merge priv/gettext --locale fr@formal before you configure your Gettext backend with your plurals module.

Thanks for your answer Kip, it seems that this doesn’t help unfortunately.

I removed plural_forms: MyApp.Plural in use Gettext, otp_app: :my_app, plural_forms: MyApp.Plural and ran the mix gettext.merge priv/gettext --locale fr@formal command. I get the same error.

Sorry to hear that. I just created a new app with a gettext backend and no plurals module. And then:

% mix gettext.merge priv/gettext --locale fr@formal
Created directory priv/gettext/fr@formal/LC_MESSAGES

It seemed to be fine creating the locale files. Afraid I’m out of ideas as this stage.

Something must be wrong on my end then. Can I ask how you create your new app? I ran into the same issue with a phoenix app I created with a simple mix phx.new test-app

I just just mix new my_app (ie not Phoenix) although that really shouldn’t matter.

Did you ever find a solution to this @RealVidy? I have the exact same issue.

Unfortunately, no I gave up on the idea.

I have not retried recently though.

In the docs I noticed this line:

Notice that tasks such as mix gettext.merge use the plural backend configured under the :gettext application, so generally speaking the first format is preferred.

where the “first format” is setting the Plural module in config.exs like such:

config :gettext, :plural_forms, MyApp.Plural

Have you tried this as well?

Thanks for the suggestion @APB9785, yes, I read the same thing and that’s how I configure my custom plural module. It works perfectly when running the app but the mix task still fails.

There’s an easy workaround, you can provide the plural forms as an argument like this mix gettext.merge priv/gettext/ --locale custom_locale --plural-forms 2 as the task only seems to need the plural module to find the number of plural forms, but it would still be nice to understand what I’m doing wrong. I can also go into iex (with -S mix) and call the functions in my module just fine, though I guess that doesn’t prove much of anything.

I may well be doing something wrong, but it seems to at least be something missing from the docs about how to get this working in a Phoenix context.

In Gettext.Merger the code to resolve the n_plurals for a locale centres around the following code:

  defp put_plural_forms_opt(opts, headers, locale) do
    Keyword.put_new_lazy(opts, :plural_forms, fn ->
      read_plural_forms_from_headers(headers) ||
        Application.get_env(:gettext, :plural_forms, Gettext.Plural).nplurals(locale)
    end)
  end

  defp read_plural_forms_from_headers(headers) do
    Enum.find_value(headers, fn header ->
      with "Plural-Forms:" <> rest <- header,
           "nplurals=" <> rest <- String.trim(rest),
           {plural_forms, _rest} <- Integer.parse(rest) do
        plural_forms
      else
        _other -> nil
      end
    end)
  end

Notice that resolving the n-plurals during a merge is:

      read_plural_forms_from_headers(headers) ||
        Application.get_env(:gettext, :plural_forms, Gettext.Plural).nplurals(locale)

And read_plural_forms_from_headers/1 received headers from the “old” .po file. In the case of a new locale, the “old” file is actually the .pot file. This from the mix task .

Therefore I wonder if the .pot file has a Plural-Forms: header that is superceding the custom plurals module?