Overriding section names

[noraj]

Describe the problem

We can't translate section names.

How would the new feature work?

Adding an additional section_names: option to TTY::Option::Formatter#initialize.

Drawbacks

None I can think of.

Workaround

Hardcore ugly monkey patching, e.g. for French translation

module TTY
  module Option
    class Formatter
      def initialize(parameters, usage, param_display: DEFAULT_PARAM_DISPLAY,
                     width: DEFAULT_WIDTH, order: DEFAULT_ORDER, indent: 0)
        @parameters = parameters
        @usage = usage
        @param_display = param_display
        @order = order
        @width = width
        @indent = indent
        @space_indent = SPACE * indent
        @param_indent = indent + 2
        @section_names = {
          usage: "Utilisation :",
          arguments: "Arguments :",
          keywords: "Mots clés :",
          options: "Options :",
          env: "Environement :",
          examples: "Exemples :"
        }
      end
    end
  end
end

[piotrmurach]

Thank you for reporting this. It would be a good improvement. Do you have time to explore PR?

I wonder if there is a more generic translation approach that could be explored here that would include any text in the gem like error messages etc.

Another way would be to use the current implementation to replace the content like so:

help do |sections|
  @section_names.each do |name, header|
    sections[name].content = sections[name].content.gsub(/#{header}/, @translations[name])
  end
end

[noraj]

Another way would be to use the current implementation to replace the content like so:

I thought about that but struggled to come to something working.

Do you have time to explore PR?

It depends on how you wish to implement this.

[piotrmurach]

These are some "quick" thoughts. I believe this should be done in two steps.

First extract all the strings from the gem source such as errors or section names and place them in translations.rb as a hash:

messages = {
  errors: {
    invalid_argument: "value of `%{value}`...",
    invalid_arity: "%{type} %{name} should appear..."
  },
  sections: {
    arguments: "Arguments: ",
    keywords: "Keywords: "
  },
  ...
}

Then we could have a top-level lookup method that would rely on backend to find translations internally:

def translate(key, **tokens)
  backend.translate(key, **tokens)
end

By default, the memory backend could be used that checks translations against messages:

def translate(key, tokens)
  message = messages[key]
  if message && message.with_tokens?
    message % tokens
  else
    message
  end
end

And we could also try to have i18n backend that would work out of the box when available. I don't want tty-option to have any dependencies.

Once we have messages extracted internally. Then, in the class that includes TTY::Options we could expose some translations configuration DSL.

Either to directly override messages:

translations["sections.arguments"] = "..."
translations["sections.keywords"] = "..."

Or, allow configuration in a block that mimics i18n options:

translations do
  backend :i18n
  default_locale :en
  load_path "config/locales/en.yml"
end

Any translations provided via any of the two methods would be "merged" with the default messages before performing translation.

As mentioned, these are some quick sketches of where we could take this. Any thoughts?