Skip to content

i18n_202206_1

Jump to bottom
Tsukasa OI edited this page Oct 4, 2022 · 5 revisions

I18N: Consistency Fix (June 2022)

Issues Fixed

This patchset intends to resolve some i18n issues.

1. gas/config/obj-macho.c: wrap two strings (PATCH 1/2)

On collect_16char_name on this file, there's a formatted error message:

as_bad (_("the %s name '%s' is too long (maximum 16 characters)"),
           msg, namstart);

collect_16char_name is called by obj_mach_o_get_section_names but it does not wrap input msg parameter. Quoting from the function:

if (collect_16char_name (seg, "segment", 1))
collect_16char_name (sec, "section", 0);

The words "segment" and "section" should be wrapped with _().

This is not a problem on French but it IS on Spanish. I quote some Spanish translation from gas/po/es.po:

#: config/obj-macho.c:119
#, c-format
msgid "the %s name '%s' is too long (maximum 16 characters)"
msgstr "el nombre %s «%s» es demasiado largo (máximo 16 caracteres)"

#: config/tc-aarch64.c:607 config/tc-arm.c:1072 config/tc-i860.c:1003
#: config/tc-sparc.c:3440
msgid "bad segment"
msgstr "segmento equivocado"

#: config/tc-alpha.c:4274
#, c-format
msgid "unknown section attribute %s"
msgstr "atributo seccional %s desconocido"

It will have following mappings on Spanish:

English Spanish
segment segmento
section seccional

In Japanese (the language I am trying to translate some GAS strings), it will be visiblly significant:

Sample message in English:
    the section name 'ABC...' is too long (maximum 16 characters)
Possible Japanese translation without this patch:
    section 名 'ABC...' が長すぎます (最大 16 文字)
Possible Japanese translation with this patch:
    セクション名 'ABC...' が長すぎます (最大 16 文字)

In here, an English word "section" stands out too much in otherwise Japanese message. If we can translate the word "section" (technically, transliterate) to "セクション" (Hepburn: sekushon), the whole sentense gets more natural.

It will have following mappings on Japanese:

English Japanese
segment セグメント
section セクション

2. gas/config/tc-riscv.c: consistency (PATCH 2/2)

This is about consistency. Quoting some from riscv_ip, there are similar error messages here:

as_bad (_("bad value for compressed funct6 "
          "field, value must be 0...64"));
as_bad (_("bad value for compressed funct4 "
          "field, value must be 0...15"));
as_bad (_("bad value for compressed funct3 "
          "field, value must be 0...7"));
as_bad (_("bad value for compressed funct2 "
          "field, value must be 0...3"));

You can see the difference. For funct2, funct3 and funct4, ranges in error strings are 0...(2^n-1). However on funct6, range in the error string is 0...(2^n).

This commit fixes this inconsistency by changing from 0...64 to 0...63.

Clone this wiki locally