translation-i18n — Discussion of software translation techniques

[Translation-i18n] KDE Lokalize: Generate pot from source files?

[<c....@po...>]

Hello there,

I try to find a good "workflow" or toolchain to get translations done in 
my Python project. Most platforms (including "Translatiol Project" I 
think) do use pot files but they don't generate them.
I have to run pygettext3 (or xgettext, ...) myself to scan source files 
an generate or update the po-template and the po-files (message 
cataloges). I don't want to do that myself. ;)

I have tried KDE Lokalize because I read somewhere (couldn't find the 
source again) that it is able to generate po files. But I can not find 
the feature in the GUI of that application. Does anyone know where it 
could be?

Or does anyone know an alternative GUI or web-platform that can take my 
upstream repo and the py files in it an do all the 
po-file-generating-merging-handling-etc itself?

Kind
Christian

[Translation-i18n] Project ID and POT filename discrepancy.

[Agron S. <as9...@gm...>]

Hello team,

I was wondering if there is any script that fixes the project ID in the POT
files to make them match because I keep forgetting until the robot rejects
it.

In fact, if you look at sudo pot (multiple versions, if not all) you will
see that the ProjectID in them does not match the filename.

If there a script like that please let me know. I could fix all POT files
with it.

Thanks,
//Agron

[Translation-i18n] xgettext flag arguments for c++ fmt library

[Daniel L. P. <Dan...@sp...>]

Hello,

I've been searching online for an answer to this question but I couldn't find anything relevant, I'm hoping someone on this list has an answer or can point me in the right direction.

I have a c++ project that is using cppformat, now named fmt, library. It has modeled it's formatting syntax (https://fmt.dev/latest/syntax.html) like python's str.format.  I would like to have xgettext's prepend the flag to denote the format of the extracted string of :, python-brace-style so that tools like POEdit will verify the correct syntax for our strings.


We also use the _() macro that is overloaded to call one of the three functions, we use a keyword arguments of: 
* -k_:1c,2,2t ( double argument call, with context and string to translate)
* -k_:1,2,3t ( triple argument call for plurals )
* -k_:1,1t ( single argument call for simple substitution)

I don't see in the documentation a similar syntax for the flags argument to xgettext.  Does xgettext support overloading for flags?  How do I support c++ with python styled format strings?

Thanks for any insight you can provide,

Daniel Perry



Daniel Perry | Senior Software Engineer
d +1 (803) 802 1534
Spectrum Medical Inc | o +1 (800) 265 2331 | f +1 (803) 802 1455
481 Munn Road | Suite 180 | Fort Mill | SC | 29715
www.spectrummedical.com
CONFIDENTIALITY NOTICE
This message is sent by Spectrum Medical. The message and the information it contains or has attached is confidential and is intended solely for the use of the named addressee. If you have received this message in error, we apologise. Please destroy it immediately. In the meantime, you should not disclose this message and/or the information it contains or has attached to any other person, nor make any copies. Any views expressed in the message and/or attachments are those of the individual sender, except when the message states otherwise and the sender is authorised to state them to be the views of the company. All reasonable precautions have been taken to ensure no viruses are present in this e-mail. Spectrum Medical does not accept responsibility for any damage whatsoever arising from the use of this e-mail or attachments and recommend that you subject these to your virus checking procedures prior to use.
Registered Office: Harrier 4, Meteor Business Park, Cheltenham Road East, Gloucester, GL2 9QL
Company Registration Number: 9762837
​v202012011056

[Translation-i18n] xgettext's --sort-output considered harmful?

[Lauri N. <la...@ik...>]

Hello all,

xgettext has the argument -s with the description:

-s, --sort-output           generate sorted output

The official Gettext documentation 
<https://www.gnu.org/software/gettext/manual/html_node/xgettext-Invocation.html#Output-details> 
itself points out that "using this option makes it much harder for the 
translator to understand each message’s context".

When should this argument and sorted output actually be used? To me it 
seems sorting msgids of a POT file only has one huge disadvantage and no 
advantages. Messages related to each other are often placed far away 
from each other in files that translators work on.

Despite the warning in Gettext documentation, the output of "xgettext 
--help" doesn't point out the harmfulness, and in real world some 
projects generate their POTs sorted alphabetically. Probably without 
giving much though to "why"; sorting something just sounds elegant.

So,

1. Is --sort-output useful in some use case I can't think of?

2. Should the --help description be complemented with something like 
"(not recommended)" or "(use with caution)"?


Best Regards,
LN

[Translation-i18n] (no subject)

[khamdy s. <kha...@gm...>]

Dear Sir/Madam,

I am interested about your translation project. I would like to ask you
that now the project still need translator? If still need how can i apply
to work as translator.

Looking forward to hear from you.

Best regard,

khamdy

Re: [Translation-i18n] Mailing list server

[Göran U. <go...@ud...>]

Paul Smith:
> If they were migrated to the GNU-managed list service, for example,

Are you talking about an actual SERVICE here?  If so, do you have a
pointer?  Or are you just talking about using a GNU Mailman server,
but managing it ourselves?

Re: [Translation-i18n] Mailing list server

[Göran U. <go...@ud...>]

Lauri Nurmi:
> This could be doable if the most obvious spam is automatically filtered 
> out and the moderation queue stays relatively short, but this does not 
> seem to be the case at Sourceforge. But ultimately there seem to be very 
> very few people interested in reporting translation bugs in Finnish, or 
> discussing translation.

It sounds like we've just been lucky that our current server manager
(the student organisation at the Blekinge Institute of Technology)
have a server that does most of the filtering.  It depends of course
on how often I check, but it's typically just a handful of mails I
have to scan and throw away.  You are right that it is rare that
anyone actually sends a valid comment, but it does happen
occasionally.  It is typically trivial to judge from the subject lines
when this happens.

Re: [Translation-i18n] Mailing list server

[Paul S. <ps...@gn...>]

On Mon, 2020-04-27 at 19:08 +0300, Lauri Nurmi wrote:
> This could be doable if the most obvious spam is automatically
> filtered out and the moderation queue stays relatively short, but this
> does not seem to be the case at Sourceforge.

I wonder why these lists are still being run through sourceforge.

That is really not a great system and has not been for a while (IMO).

If they were migrated to the GNU-managed list service, for example, then
there is a whole host of automatic spam filtering added to their mailman
installation which makes it quite trivial to moderate lists with almost no
extra effort.

I don't know what would be involved with migrating but maybe it's something
to consider.

Re: [Translation-i18n] Mailing list server

[Lauri N. <la...@ik...>]

Göran Uddeborg kirjoitti 27.4.2020 klo 17:28:
> Lauri Nurmi:
>
>> I wonder how useful it is to have a mailing list address in the
>> translations in the first place.
> We don't ONLY use it IN the translations.  We use it for the
> announcements from the project, and for internal discussions.  We need
> a list in any case.
>
> In the translations the pointer on where to report translation errors,

Just to clarify, I am not questioning the benefits of a mailing list, 
just using the mailing list's bare email address as the pointer for 
random error reports by random end users.

> Do you have a web site for this?  I checked a couple of Finnish
> translations, but none of them had any of the traditional "report bugs
> in the translation to ..."

We don't have a web site, and while at some point we generally had the 
traditional "report translation bugs to ..." lines there, along with the 
team's mailing list address, lately I have been removing those. My 
reason for that was simply that in the rare case that someone would 
actually send a bug report to the address, it would no doubt go 
unnoticed, because it is frozen for moderation, and going through the 
moderation queue is simply too much work for no gain. Nowadays the 
active Finnish team mostly consist of me alone.

I have thought about providing the mailing list's subscription page URL 
instead in the translations, i.e. 
<https://sourceforge.net/projects/translation/lists/translation-team-fi> 
in our case. That way it would be more clear where to subscribe, and 
that subscription is necessary.

>
>> Any mailing list accepting mail from non-subscribers would be
>> filled with spam at this day and age.
> That is true.  We as maintainers (mostly myself I belive) have to go
> through the list of non-subscriber mails from time to time and check
> if there is any valid mails there.  But compared to managing a bug
> reporting site, I believe it is much less.

This could be doable if the most obvious spam is automatically filtered 
out and the moderation queue stays relatively short, but this does not 
seem to be the case at Sourceforge. But ultimately there seem to be very 
very few people interested in reporting translation bugs in Finnish, or 
discussing translation.

Re: [Translation-i18n] Mailing list server

[Göran U. <go...@ud...>]

Lauri Nurmi:
> Sourceforge does not allow even the list's administrator to view the 
> list of list subscribers, which can be quite a limitation, especially if 
> you'd like to move the list somewhere else and keep current subscribers.

Oh, that does not sound like a good option then.

> I wonder how useful it is to have a mailing list address in the 
> translations in the first place.

We don't ONLY use it IN the translations.  We use it for the
announcements from the project, and for internal discussions.  We need
a list in any case.

In the translations the pointer on where to report translation errors,
we could point to a web page instead.  But even if it wasn't for the
other uses of the mailing list, that would not really solve the
problem.  That site would also need to be managed.  It would have to
have some kind of bug reporting system.  It sounds to me as even more
maintenance than a plain mailing list.

Do you have a web site for this?  I checked a couple of Finnish
translations, but none of them had any of the traditional "report bugs
in the translation to ..." sections added to the bug reporting
address.  Don't you have any way to report that, or was I just unlucky
in my choice of translations?

> Any mailing list accepting mail from non-subscribers would be 
> filled with spam at this day and age.

That is true.  We as maintainers (mostly myself I belive) have to go
through the list of non-subscriber mails from time to time and check
if there is any valid mails there.  But compared to managing a bug
reporting site, I believe it is much less.

Re: [Translation-i18n] Mailing list server

[Lauri N. <la...@ik...>]

Göran Uddeborg kirjoitti 21.4.2020 klo 14:16:
> The provider of the list for the Swedish translation team
> <tp...@li...>, have announced they will shortly stop running
> a mailing list server.
>
> What are your experiences with Sourceforge these
> days, and in particular using their mailing lists?

Sourceforge does not allow even the list's administrator to view the 
list of list subscribers, which can be quite a limitation, especially if 
you'd like to move the list somewhere else and keep current subscribers.

> Would it be possible to add a Swedish list there too?  If so, is there any way to
> make it accept the current address, or would we have to change every
> reference we have in every translation?

I wonder how useful it is to have a mailing list address in the 
translations in the first place. Would a web site address be more 
useful? Any mailing list accepting mail from non-subscribers would be 
filled with spam at this day and age. A mailing list email address on 
its own also doesn't tell how to properly subscribe to that list.

[Translation-i18n] Mailing list server

[Göran U. <go...@ud...>]

Hello, fellow translation coordinators!

The provider of the list for the Swedish translation team
<tp...@li...>, have announced they will shortly stop running
a mailing list server.  We are looking for a new home for it.  Does
anyone here have any good suggestions?

I note that this list, and a number of teams' lists, are hosted at
sourceforge.net.  What are your experiences with Sourceforge these
days, and in particular using their mailing lists?  Would it be
possible to add a Swedish list there too?  If so, is there any way to
make it accept the current address, or would we have to change every
reference we have in every translation?

[Translation-i18n] COLLABORATION WITH THE TRANSLATION TEAM

[Greta L. S. D'A. <gre...@gm...>]

Hi,
I wish to contribute with the Linux Documentation Project, specially in the
translation area. I can handle translations from English to Spanish and
from English to Italian. I was thinking that I could translate with no
problem the HOWTO articles and also the guides.
I'm a student of Languages in the National University of Córdoba,
Argentina, and this collaborations could be a good antecedent in my career.
If you are interested, I'm ready to start when you consider it appropriate.
Thank you in advance.

Regards,

Greta Sigwald

Re: [Translation-i18n] Language & country code getter

[Krock <mk...@ym...>]

[This message was originally sent on August 20th, but I forgot to CC the 
mailing list. Sorry for the trouble]

Good day,

> I don't see where you would be using 'setlocale'.
> On the server? You don't need to set a locale to send a data file.
> On the client? You don't need to set a locale to look up a message in a
> data file, if you use one of the other output formats that 'msgfmt'
> supports [2].
>
> But yes, sometimes you need to convert locale names, e.g.
>    de-de -> de_DE
>    zh-Hans -> zh_CN
>    zh-Hant-> zh_TW
> or vice versa. In GNU we don't have such a conversion routine so far,
> but it's easy to write. ICU has such functions [3].
I am glad to see those conversion functions available in ICU; they would
provide the wanted solution for my question. However, depending on ICU
to call to a single API function (most likely `uloc_getDisplayLanguage`)
to implement a barely used feature is unreasonable. When there's more
demand for proper Unicode/locale handling, it might be a wise long-term
decision to make it a requirement in Minetest.
`setlocale(LC_ALL, "")` was experimentally used to read the currently
active locale code for the client. It might be best to elaborate how the
server-sent translation system was intended to work:

1) Client sends priority list of the locale codes to the server
2) Server sends the matching translation files to the client for in-game use
3) Client loads the available translation files given by its locale priority

> You can usually assume that the 'Language' header is consistent with the
> file name. Therefore, no need to extract the header from within the message
> catalog.

Step 1 above requires to get the locale code in a fixed format to send
it to the server. It is possible to change the language by a game
setting, which is then applied on startup.
And here comes the dirty chain of the translation management:
1) Gettext does not seem to support unloading textdomains or catalogues
     -> A rudimentary string replacement function was implemented for
in-game use; to translate content descriptions which may vary per server.
2) Gettext does not expose the currently active language, which would be
in the wanted ISO format ($lang from your example)
     -> The language is currently "detected" by a custom magic string
"LANG_CODE" which is then translated to "fr", "pt_BR" depending on the
loaded translation. This arises the issue that the server can only send
translations to the client where also gettext translations for the basic
UI exist.

Translating the reserved empty string ("") to get the language header
(and with it - the currently used file) would be a plausible and rather
simple workaround to replace "LANG_CODE" and to get a consistent locale
code formatting.

Thank you for your input. But I am afraid of that the current
workarounds provide a simpler and faster solution.
Gettext lacks of two functions, which caused this overly complex problem
for what it should do at the end.

- Krock

> [1] https://tools.ietf.org/html/rfc7231#section-5.3.5
> [2] https://www.gnu.org/software/gettext/manual/html_node/msgfmt-Invocation.html
> [3] http://icu-project.org/apiref/icu4c/uloc_8h.html

[Translation-i18n] Translation

[assaf r. <ass...@gm...>]

What’s this,exactly about?
Assaf Rosenkrantz.

נשלח מה-iPhone שלי Assaf Rosenkrantz 

Re: [Translation-i18n] Language & country code getter

[Bruno H. <br...@cl...>]

Hello,

> I am currently working on a feature for the game Minetest to send 
> relevant translation files from the server to the clients according to 
> the clients language loading priority list.

Indeed, in a client-server situation, the common practice is to send
entire translation files, not individual translated strings, and
ignore the glibc functions gettext(), dgettext(), etc., because
  - this reduces the number of networking-related delays,
  - gettext(), dgettext(), etc. require the corresponding locale to
    be present; however, system administrators often don't have 100
    pregenerated locales installed.

> Such a list may look like { 
> "en", "de", "de_DE" } whereas "de_DE" would be the best-fitting match in 
> case such translation files were found.

Yes, the same idea is used for HTTP clients, where the 'Accept-Language'
header contains the user's preference list. [1]

> Problem: The output of the C function `setlocale` does not follow any 
> standard and depends on the platform, so getting the currently used 
> language in a fixed format would be very helpful.

I don't see where you would be using 'setlocale'.
On the server? You don't need to set a locale to send a data file.
On the client? You don't need to set a locale to look up a message in a
data file, if you use one of the other output formats that 'msgfmt'
supports [2].

But yes, sometimes you need to convert locale names, e.g.
  de-de -> de_DE
  zh-Hans -> zh_CN
  zh-Hant-> zh_TW
or vice versa. In GNU we don't have such a conversion routine so far,
but it's easy to write. ICU has such functions [3].

> My question is: Gettext already knows about the language and country 
> codes to load the appropriate (LC_MESSAGES) translation file. Is there 
> an API function to get the currently active locale identifier (ex. 
> "en_US" or "en")?

Usually this information is encoded in the file name. For example,
in a source tree, the files are usually in
  po/$lang.po
and .mo files are usually installed in
  $PREFIX/locale/$lang/LC_MESSAGES/$package.mo

> Or using a different approach: Is there an API function to read the 
> `Language` header entry value from the translation file, like it is 
> specified/defined here: 
> https://www.gnu.org/software/gettext/manual/html_node/Header-Entry.html ?

You can usually assume that the 'Language' header is consistent with the
file name. Therefore, no need to extract the header from within the message
catalog.

Bruno

[1] https://tools.ietf.org/html/rfc7231#section-5.3.5
[2] https://www.gnu.org/software/gettext/manual/html_node/msgfmt-Invocation.html
[3] http://icu-project.org/apiref/icu4c/uloc_8h.html

[Translation-i18n] [gettext] Language & country code getter

[Krock <mk...@ym...>]

Hello,


I am currently working on a feature for the game Minetest to send 
relevant translation files from the server to the clients according to 
the clients language loading priority list. Such a list may look like { 
"en", "de", "de_DE" } whereas "de_DE" would be the best-fitting match in 
case such translation files were found.

Problem: The output of the C function `setlocale` does not follow any 
standard and depends on the platform, so getting the currently used 
language in a fixed format would be very helpful.

My question is: Gettext already knows about the language and country 
codes to load the appropriate (LC_MESSAGES) translation file. Is there 
an API function to get the currently active locale identifier (ex. 
"en_US" or "en")?

Or using a different approach: Is there an API function to read the 
`Language` header entry value from the translation file, like it is 
specified/defined here: 
https://www.gnu.org/software/gettext/manual/html_node/Header-Entry.html ?


Thanks in advance for your time.

- Krock

Re: [Translation-i18n] xtensa message pluralization

[Alan M. <am...@gm...>]

On Fri, Nov 10, 2017 at 10:37:24AM +0000, Pedro Alves wrote:
> On 11/09/2017 07:04 PM, Bruno Haible wrote:
> > Or omit one of the plurals or even both plurals:
> >     "Mismatch for format '%s': #slots = %d, #opcodes = %d."
> > Admittedly this is not so pretty, but in tabular displays this is how
> > numbers are often printed, so that plural forms don't appear at all.
> 
> +1.  I was going to suggest this direction too.

OK, I'll go that way with following patch since I haven't heard any
preference otherwise.

	* config/tc-xtensa.c (finish_vinsn): Avoid multiple ngettext calls
	in error message.

diff --git a/gas/config/tc-xtensa.c b/gas/config/tc-xtensa.c
index 3fe85d2..a48ce1e 100644
--- a/gas/config/tc-xtensa.c
+++ b/gas/config/tc-xtensa.c
@@ -6323,6 +6323,7 @@ finish_vinsn (vliw_insn *vinsn)
 {
   IStack slotstack;
   int i;
+  int slots;
 
   if (find_vinsn_conflicts (vinsn))
     {
@@ -6334,7 +6335,8 @@ finish_vinsn (vliw_insn *vinsn)
   if (vinsn->format == XTENSA_UNDEFINED)
     vinsn->format = xg_find_narrowest_format (vinsn);
 
-  if (xtensa_format_num_slots (xtensa_default_isa, vinsn->format) > 1
+  slots = xtensa_format_num_slots (xtensa_default_isa, vinsn->format);
+  if (slots > 1
       && produce_flix == FLIX_NONE)
     {
       as_bad (_("The option \"--no-allow-flix\" prohibits multi-slot flix."));
@@ -6355,23 +6357,11 @@ finish_vinsn (vliw_insn *vinsn)
       return;
     }
 
-  if (vinsn->num_slots
-      != xtensa_format_num_slots (xtensa_default_isa, vinsn->format))
+  if (vinsn->num_slots != slots)
     {
-      char *msg;
-      int slots = xtensa_format_num_slots (xtensa_default_isa, vinsn->format);
-
-      msg = concat (ngettext ("format '%s' allows %d slot, ",
-			      "format '%s' allows %d slots, ",
-			      slots),
-		    ngettext ("but there is %d opcode",
-			      "but there are %d opcodes",
-			      vinsn->num_slots),
-		    (const char *) 0);
-
-      as_bad (msg, xtensa_format_name (xtensa_default_isa, vinsn->format),
+      as_bad (_("mismatch for format '%s': #slots = %d, #opcodes = %d"),
+	      xtensa_format_name (xtensa_default_isa, vinsn->format),
 	      slots, vinsn->num_slots);
-      free (msg);
       xg_clear_vinsn (vinsn);
       return;
     }

-- 
Alan Modra
Australia Development Lab, IBM

[Translation-i18n] ld einfo positional arg support

[Alan M. <am...@gm...>]

To allow translators to reorder values in translated strings.  This
should mean that all binutils messages now have support for
reordering.

Note to translators:  Not all % letters take arguments, so for example
the following only has two arguments, the two %s strings.
"%P%F: output format %s cannot represent section called %s: %E\n"

You could reorder this if you liked to:
"%P%F: %E: section %2$s cannot be represented in output format %1$s\n"

einfo lacks support for flags, field width, precision and length
modifier (apart from %ld and %lu) so don't try to use them in
translations.  Both ld and bfd lack support to use a positional arg
twice.  These features could be added if needed..

	* ldmisc.c (vfinfo): Support up to 9 positional args.

diff --git a/ld/ldmisc.c b/ld/ldmisc.c
index 420ddb1..da499e9 100644
--- a/ld/ldmisc.c
+++ b/ld/ldmisc.c
@@ -23,6 +23,7 @@
 #include "bfd.h"
 #include "bfdlink.h"
 #include "libiberty.h"
+#include "safe-ctype.h"
 #include "filenames.h"
 #include "demangle.h"
 #include <stdarg.h>
@@ -65,10 +66,140 @@
 */
 
 void
-vfinfo (FILE *fp, const char *fmt, va_list arg, bfd_boolean is_warning)
+vfinfo (FILE *fp, const char *fmt, va_list ap, bfd_boolean is_warning)
 {
   bfd_boolean fatal = FALSE;
+  const char *scan;
+  int arg_type;
+  unsigned int arg_count = 0;
+  unsigned int arg_no;
+  union vfinfo_args
+  {
+    int i;
+    long l;
+    void *p;
+    bfd_vma v;
+    struct {
+      bfd *abfd;
+      asection *sec;
+      bfd_vma off;
+    } reladdr;
+    enum
+      {
+	Bad,
+	Int,
+	Long,
+	Ptr,
+	Vma,
+	RelAddr
+      } type;
+  } args[9];
+
+  for (arg_no = 0; arg_no < sizeof (args) / sizeof (args[0]); arg_no++)
+    args[arg_no].type = Bad;
+
+  arg_count = 0;
+  scan = fmt;
+  while (*scan != '\0')
+    {
+      while (*scan != '%' && *scan != '\0')
+	scan++;
+
+      if (*scan == '%')
+	{
+	  scan++;
+
+	  arg_no = arg_count;
+	  if (*scan != '0' && ISDIGIT (*scan) && scan[1] == '$')
+	    {
+	      arg_no = *scan - '1';
+	      scan += 2;
+	    }
+
+	  arg_type = Bad;
+	  switch (*scan++)
+	    {
+	    case '\0':
+	      --scan;
+	      break;
+
+	    case 'V':
+	    case 'v':
+	    case 'W':
+	      arg_type = Vma;
+	      break;
+
+	    case 'T':
+	    case 'A':
+	    case 'B':
+	    case 'I':
+	    case 'S':
+	    case 'R':
+	    case 'p':
+	    case 's':
+	      arg_type = Ptr;
+	      break;
+
+	    case 'C':
+	    case 'D':
+	    case 'G':
+	    case 'H':
+	      arg_type = RelAddr;
+	      break;
+
+	    case 'd':
+	    case 'u':
+	      arg_type = Int;
+	      break;
+
+	    case 'l':
+	      if (*scan == 'd' || *scan == 'u')
+		{
+		  ++scan;
+		  arg_type = Long;
+		}
+	      break;
+
+	    default:
+	      break;
+	    }
+	  if (arg_type != Bad)
+	    {
+	      if (arg_no >= sizeof (args) / sizeof (args[0]))
+		abort ();
+	      args[arg_no].type = arg_type;
+	      ++arg_count;
+	    }
+	}
+    }
 
+  for (arg_no = 0; arg_no < arg_count; arg_no++)
+    {
+      switch (args[arg_no].type)
+	{
+	case Int:
+	  args[arg_no].i = va_arg (ap, int);
+	  break;
+	case Long:
+	  args[arg_no].l = va_arg (ap, long);
+	  break;
+	case Ptr:
+	  args[arg_no].p = va_arg (ap, void *);
+	  break;
+	case Vma:
+	  args[arg_no].v = va_arg (ap, bfd_vma);
+	  break;
+	case RelAddr:
+	  args[arg_no].reladdr.abfd = va_arg (ap, bfd *);
+	  args[arg_no].reladdr.sec = va_arg (ap, asection *);
+	  args[arg_no].reladdr.off = va_arg (ap, bfd_vma);
+	  break;
+	default:
+	  abort ();
+	}
+    }
+
+  arg_count = 0;
   while (*fmt != '\0')
     {
       const char *str = fmt;
@@ -83,8 +214,20 @@ vfinfo (FILE *fp, const char *fmt, va_list arg, bfd_boolean is_warning)
       if (*fmt == '%')
 	{
 	  fmt++;
+
+	  arg_no = arg_count;
+	  if (*fmt != '0' && ISDIGIT (*fmt) && fmt[1] == '$')
+	    {
+	      arg_no = *fmt - '1';
+	      fmt += 2;
+	    }
+
 	  switch (*fmt++)
 	    {
+	    case '\0':
+	      --fmt;
+	      /* Fall through.  */
+
 	    case '%':
 	      /* literal % */
 	      putc ('%', fp);
@@ -98,7 +241,8 @@ vfinfo (FILE *fp, const char *fmt, va_list arg, bfd_boolean is_warning)
 	    case 'V':
 	      /* hex bfd_vma */
 	      {
-		bfd_vma value = va_arg (arg, bfd_vma);
+		bfd_vma value = args[arg_no].v;
+		++arg_count;
 		fprintf_vma (fp, value);
 	      }
 	      break;
@@ -108,7 +252,8 @@ vfinfo (FILE *fp, const char *fmt, va_list arg, bfd_boolean is_warning)
 	      {
 		char buf[100];
 		char *p = buf;
-		bfd_vma value = va_arg (arg, bfd_vma);
+		bfd_vma value = args[arg_no].v;
+		++arg_count;
 		sprintf_vma (p, value);
 		while (*p == '0')
 		  p++;
@@ -127,7 +272,8 @@ vfinfo (FILE *fp, const char *fmt, va_list arg, bfd_boolean is_warning)
 		char *p;
 		int len;
 
-		value = va_arg (arg, bfd_vma);
+		value = args[arg_no].v;
+		++arg_count;
 		sprintf_vma (buf, value);
 		for (p = buf; *p == '0'; ++p)
 		  ;
@@ -146,8 +292,8 @@ vfinfo (FILE *fp, const char *fmt, va_list arg, bfd_boolean is_warning)
 	    case 'T':
 	      /* Symbol name.  */
 	      {
-		const char *name = va_arg (arg, const char *);
-
+		const char *name = (const char *) args[arg_no].p;
+		++arg_count;
 		if (name == NULL || *name == 0)
 		  {
 		    fprintf (fp, _("no symbol"));
@@ -173,11 +319,14 @@ vfinfo (FILE *fp, const char *fmt, va_list arg, bfd_boolean is_warning)
 	    case 'A':
 	      /* section name from a section */
 	      {
-		asection *sec = va_arg (arg, asection *);
-		bfd *abfd = sec->owner;
+		asection *sec;
+		bfd *abfd;
 		const char *group = NULL;
 		struct coff_comdat_info *ci;
 
+		sec = (asection *) args[arg_no].p;
+		++arg_count;
+		abfd = sec->owner;
 		fprintf (fp, "%s", sec->name);
 		if (abfd != NULL
 		    && bfd_get_flavour (abfd) == bfd_target_elf_flavour
@@ -197,8 +346,8 @@ vfinfo (FILE *fp, const char *fmt, va_list arg, bfd_boolean is_warning)
 	    case 'B':
 	      /* filename from a bfd */
 	      {
-		bfd *abfd = va_arg (arg, bfd *);
-
+		bfd *abfd = (bfd *) args[arg_no].p;
+		++arg_count;
 		if (abfd == NULL)
 		  fprintf (fp, "%s generated", program_name);
 		else if (abfd->my_archive != NULL
@@ -230,7 +379,8 @@ vfinfo (FILE *fp, const char *fmt, va_list arg, bfd_boolean is_warning)
 	      {
 		lang_input_statement_type *i;
 
-		i = va_arg (arg, lang_input_statement_type *);
+		i = (lang_input_statement_type *) args[arg_no].p;
+		++arg_count;
 		if (i->the_bfd->my_archive != NULL
 		    && !bfd_is_thin_archive (i->the_bfd->my_archive))
 		  fprintf (fp, "(%s)",
@@ -247,8 +397,8 @@ vfinfo (FILE *fp, const char *fmt, va_list arg, bfd_boolean is_warning)
 	      /* Print script file and linenumber.  */
 	      {
 		etree_type node;
-		etree_type *tp = va_arg (arg, etree_type *);
-
+		etree_type *tp = (etree_type *) args[arg_no].p;
+		++arg_count;
 		if (tp == NULL)
 		  {
 		    tp = &node;
@@ -263,8 +413,8 @@ vfinfo (FILE *fp, const char *fmt, va_list arg, bfd_boolean is_warning)
 	    case 'R':
 	      /* Print all that's interesting about a relent.  */
 	      {
-		arelent *relent = va_arg (arg, arelent *);
-
+		arelent *relent = (arelent *) args[arg_no].p;
+		++arg_count;
 		lfinfo (fp, "%s+0x%v (type %s)",
 			(*(relent->sym_ptr_ptr))->name,
 			relent->addend,
@@ -292,9 +442,10 @@ vfinfo (FILE *fp, const char *fmt, va_list arg, bfd_boolean is_warning)
 		bfd_boolean discard_last;
 		bfd_boolean done;
 
-		abfd = va_arg (arg, bfd *);
-		section = va_arg (arg, asection *);
-		offset = va_arg (arg, bfd_vma);
+		abfd = args[arg_no].reladdr.abfd;
+		section = args[arg_no].reladdr.sec;
+		offset = args[arg_no].reladdr.off;
+		++arg_count;
 
 		if (abfd != NULL)
 		  {
@@ -394,34 +545,40 @@ vfinfo (FILE *fp, const char *fmt, va_list arg, bfd_boolean is_warning)
 
 	    case 'p':
 	      /* native (host) void* pointer, like printf */
-	      fprintf (fp, "%p", va_arg (arg, void *));
+	      fprintf (fp, "%p", args[arg_no].p);
+	      ++arg_count;
 	      break;
 
 	    case 's':
 	      /* arbitrary string, like printf */
-	      fprintf (fp, "%s", va_arg (arg, char *));
+	      fprintf (fp, "%s", (char *) args[arg_no].p);
+	      ++arg_count;
 	      break;
 
 	    case 'd':
 	      /* integer, like printf */
-	      fprintf (fp, "%d", va_arg (arg, int));
+	      fprintf (fp, "%d", args[arg_no].i);
+	      ++arg_count;
 	      break;
 
 	    case 'u':
 	      /* unsigned integer, like printf */
-	      fprintf (fp, "%u", va_arg (arg, unsigned int));
+	      fprintf (fp, "%u", args[arg_no].i);
+	      ++arg_count;
 	      break;
 
 	    case 'l':
 	      if (*fmt == 'd')
 		{
-		  fprintf (fp, "%ld", va_arg (arg, long));
+		  fprintf (fp, "%ld", args[arg_no].l);
+		  ++arg_count;
 		  ++fmt;
 		  break;
 		}
 	      else if (*fmt == 'u')
 		{
-		  fprintf (fp, "%lu", va_arg (arg, unsigned long));
+		  fprintf (fp, "%lu", args[arg_no].l);
+		  ++arg_count;
 		  ++fmt;
 		  break;
 		}

-- 
Alan Modra
Australia Development Lab, IBM

Re: [Translation-i18n] conditional string handling

[Bruno H. <br...@cl...>]

[Removing CCs since this is no longer directly related to binutils.]

Pau...@de... wrote:
> >  - Such an nngettext function would be overkill for a rarely used case.
> 
> That's a fair argument.  Then again, conditional string handling in Java
> properties files handles this sort of case without any trouble.

You mean the Choice format in Java's MessageFormat [1]? Yes, this has most
of the flexibility you want, except that
  1) it assumes that the translator groks the syntax the meaning of these
     patterns, or that she has a GUI tool that presents them an an intuitive
     way. Usually neither of these is the case, and therefore the translation
     is more often broken than correct.
  2) these Choice patterns lack the ability to dispatch on a language-
     dependent modulo expression, like n%4 or n%20. But this is precisely
     what is needed for plural forms.

So these Choice formats are in the category "nice try, but not really working
for this use-case".

Bruno

[1] https://docs.oracle.com/javase/7/docs/api/java/text/MessageFormat.html

Re: [Translation-i18n] xtensa message pluralization

[Bruno H. <br...@cl...>]

Alan Modra wrote:
> > there isn't an "nngettext" to give you the correct message for the plural based on more than one value.
> 
> ... The translation project is going to be
> faced with sentences that really do need two or more pluralized nouns
> for the sense to be conveyed naturally in English.

The former gettext maintainer's usual answer to such a request is:
  - Such an nngettext function would be overkill for a rarely used case.
  - You can usually either split the sentence into two sentences (that
    can be translated separately), or even get rid of one of the plural
    forms entirely.

> Avoiding two
> plurals in one sentence will mean loss of information (eg. dropping
> "bytes" from a quantity) or stilted contrived sentences.
> 
> To recap, the sentence we are talking about here is:
> 	"format '%s' allows %d slots, but there are %d opcodes"

You can turn it to:
    "The format '%s' allows %d slots."
    "But there are %d opcodes."

Or omit one of the plurals or even both plurals:
    "Mismatch for format '%s': #slots = %d, #opcodes = %d."
Admittedly this is not so pretty, but in tabular displays this is how
numbers are often printed, so that plural forms don't appear at all.

> In both cases the
> "slots" phrase translation can't depend on the quantity in the
> "opcodes" phrase translation, and vice versa.

Correct, and this is acceptable. You don't have to care for hypothetical
dependencies that _may_ exist between hardly related entities.
Take as model some language like French or Latin (with more grammar
than English), where
  - the variant of the verb depends on the gender of the subject,
  - the variant of the verb depends on the number of objects,
  - but otherwise sentences are unrelated.
If you can split something into separate sentences in English, you
can assume that this will work in other languages as well.

> So, abbreviating F for format, S
> for slots, O for opcodes components, a translator could arrange to
> emit FSO, SFO, OFS, OSF, but not FOS or SOF.

Given the English sentence (where the statement about the opcodes is
separate), it sounds unlikely that a translator would want to use the
order FOS or SOF.

> There is also the issue of other messages that may share "%s but %s"
> construction in the future.

Yes, but this issue can be handled through contexts [1].

Bruno

[1] https://www.gnu.org/software/gettext/manual/html_node/Contexts.html

Re: [Translation-i18n] xtensa message pluralization

[Alan M. <am...@gm...>]

On Wed, Nov 08, 2017 at 05:52:59PM +0000, Pau...@de... wrote:
> The reason for the "entire sentences" rule is that a lot of languages adjust word forms in fairly complex ways, depending not just on the number (singular/plural, etc.) but also on other considerations.  If you have two sentence fragments, in English you can typically just concatenate them and be ok.  In lots of other languages it's not that simple; the correct way to phrase part 2 may depend on what is in part 1.  A sentence is a grammatical unit, and can be translated in isolation without running into these issues.  But half a sentence cannot, at least not necessarily.

Understood, and answers my question, thanks.  Using concat is not right.

> Given the limitations of the gettext machinery, if you want clean translation there are certain message constructs you have to avoid.  It appears that messages with more than one to-be-pluralized element are such an example, since there isn't an "nngettext" to give you the correct message for the plural based on more than one value.

That isn't going to happen.  The translation project is going to be
faced with sentences that really do need two or more pluralized nouns
for the sense to be conveyed naturally in English.  Avoiding two
plurals in one sentence will mean loss of information (eg. dropping
"bytes" from a quantity) or stilted contrived sentences.

To recap, the sentence we are talking about here is:
	"format '%s' allows %d slots, but there are %d opcodes"

Bruno suggested the best solution was to break the sentence at the
conjunction "but", which is of course a natural place to break a
sentence into phrases.  (It's how I broke the sentence at first too,
when considering the reordering issue.)  The code to do that would be:

      char *phrase1, *phrase2;
      int slots = xtensa_format_num_slots (xtensa_default_isa, vinsn->format);

      if (asprintf (&phrase1, ngettext ("format '%s' allows %d slot,",
					"format '%s' allows %d slots,",
					slots),
		    xtensa_format_name (xtensa_default_isa, vinsn->format),
		    slots) == -1
	  || asprintf (&phrase2, ngettext ("there is %d opcode",
					   "there are %d opcodes",
					   vinsn->num_slots),
		       vinsn->num_slots) == -1)
	as_fatal ("%s", xstrerror (errno));

      as_bad (_("%s but %s"), phrase1, phrase2);
      free (phrase1);
      free (phrase2);

This would give a translator the following to work with:

msgid "format '%s' allows %d slot,"
msgid_plural "format '%s' allows %d slots,"
msgstr[0] ""
msgstr[1] ""

msgid "there is %d opcode"
msgid_plural "there are %d opcodes"
msgstr[0] ""
msgstr[1] ""

msgid "%s but %s"
msgstr ""

The patch I posted gives:

msgid "allows %d slot"
msgid_plural "allows %d slots"
msgstr[0] ""
msgstr[1] ""

msgid "there is %d opcode"
msgid_plural "there are %d opcodes"
msgstr[0] ""
msgstr[1] ""

msgid "format '%s' %s, but %s"
msgstr ""

Note that in both cases a translator does in fact have access to the
entire sentence, but with some restrictions.  In both cases the
"slots" phrase translation can't depend on the quantity in the
"opcodes" phrase translation, and vice versa.  Bruno's suggestion has
a further restriction in that the translation for "format" must be
adjacent to the "slots" translation.  So, abbreviating F for format, S
for slots, O for opcodes components, a translator could arrange to
emit FSO, SFO, OFS, OSF, but not FOS or SOF.

The patch I posted allows all the ordering possibilities, but the
translation for "format" can't depend on the "slots" quantity, and a
translator has a little more difficulty in piecing together the
sentence by just looking at the .pot file.

There is also the issue of other messages that may share "%s but %s"
construction in the future.  If such exist then that is another
complication for anyone wanting to reorder phrases, and a reason why
it may be better to put "format" with "but".

I think that covers all the issues I've considered.  I'm not a
linguist, and besides English only know a little German.  So I'm quite
happy to take advice, Bruno.  The only reason to extend this thread
was wondering whether you had considered everything, and to make
other binutils developers aware of the problems they cause!  I know
there is room for a lot of improvement in the binutils source
regarding translation, not least being the fact that ld's einfo
function doesn't allow reordering.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [Translation-i18n] xtensa message pluralization

[Bruno H. <br...@cl...>]

aug...@gm... wrote:
> I know almost nothing about the mechanics and best-practices of
> translation, but I am very supportive and believe it should be done.

Well, if you don't believe in the best practices for internationalization
from the GNU gettext manual [1], maybe you want to consider what other people
say on this topic [2][3][4][5].

Bruno

[1] https://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html
[2] https://www.csoftintl.com/localization/software-localization/internationalization/
    section "String Handling"
[3] https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Localization_content_best_practices
    section "Create localizable strings"
[4] https://phraseapp.com/blog/posts/localization-10-common-mistakes-in-software-localization-and-how-to-avoid-them/
    section 4
[5] http://tech.lds.org/wiki/Resources_(Internationalization_best_practices)

Re: [Translation-i18n] xtensa message pluralization

[Bruno H. <br...@cl...>]

Hi Alan,

> A question for the translation project:  I'm wondering if
> I should allow translators to change sentence construction order with
> something like the following patch?

The proposed patch violates rule #2 "Entire sentences" from [1].
In particular, it separates subject and verb of the same sentence
into different format strings. This does not work, because in some
languages the verb's form depends on the subject's gender.

Therefore it should better not be applied.

> (The issue of translators wanting to reorder sentences came to light
> recently

To fix this, apply rule #4 "Use format strings instead of string concatenation."
from ]1].

Something like this:

      msg = my_asprintf ("%s, but %s",
                         ngettext ("format '%s' allows %d slot",
                                   "format '%s' allows %d slots",
                                   slots),
                         ngettext ("there is %d opcode",
                                   "there are %d opcodes",
                                   vinsn->num_slots));

This form does not fulfil rule #2 (again!) but this is a less severe violation
because you won't have side effects between the first and the second substring
in most languages.

Translators can then do the reordering by use of POSIX format string reordering
e.g. "%2$d, whereas %1$d" [2].

Bruno

[1] https://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html
[2] https://www.gnu.org/software/gettext/manual/html_node/C.html

Re: [Translation-i18n] xtensa message pluralization

[Alan M. <am...@gm...>]

On Tue, Nov 07, 2017 at 06:47:18PM -0800, aug...@gm... wrote:
> On Tue, Nov 7, 2017 at 12:27 AM, Alan Modra <am...@gm...> wrote:
> > I'm not too certain whether this is needed, ie. whether any of the slot
> > and opcode counts can be one.  Please review.
> >
> >         * config/tc-xtensa.c (finish_vinsn): Properly pluralize error message.
> 
> Thanks for the fix. Approved.

Committed.  A question for the translation project:  I'm wondering if
I should allow translators to change sentence construction order with
something like the following patch?  Is the added flexibility
desirable when weighed against a little more complexity in .pot files?

(The issue of translators wanting to reorder sentences came to light
recently with binutils PR22397.  A patch of mine inadvertently removed
that capability from bfd messages in binutils-2.29.)

diff --git a/gas/config/tc-xtensa.c b/gas/config/tc-xtensa.c
index 3fe85d2..523a6ef 100644
--- a/gas/config/tc-xtensa.c
+++ b/gas/config/tc-xtensa.c
@@ -6358,20 +6358,24 @@ finish_vinsn (vliw_insn *vinsn)
   if (vinsn->num_slots
       != xtensa_format_num_slots (xtensa_default_isa, vinsn->format))
     {
-      char *msg;
+      char *phrase1, *phrase2;
       int slots = xtensa_format_num_slots (xtensa_default_isa, vinsn->format);
 
-      msg = concat (ngettext ("format '%s' allows %d slot, ",
-			      "format '%s' allows %d slots, ",
-			      slots),
-		    ngettext ("but there is %d opcode",
-			      "but there are %d opcodes",
-			      vinsn->num_slots),
-		    (const char *) 0);
-
-      as_bad (msg, xtensa_format_name (xtensa_default_isa, vinsn->format),
-	      slots, vinsn->num_slots);
-      free (msg);
+      if (asprintf (&phrase1, ngettext ("allows %d slot",
+					"allows %d slots",
+					slots),
+		    slots) == -1
+	  || asprintf (&phrase2, ngettext ("there is %d opcode",
+					   "there are %d opcodes",
+					   vinsn->num_slots),
+		       vinsn->num_slots) == -1)
+	as_fatal ("%s", xstrerror (errno));
+
+      as_bad (_("format '%s' %s, but %s"),
+	      xtensa_format_name (xtensa_default_isa, vinsn->format),
+	      phrase1, phrase2);
+      free (phrase1);
+      free (phrase2);
       xg_clear_vinsn (vinsn);
       return;
     }


-- 
Alan Modra
Australia Development Lab, IBM