You can subscribe to this list here.
2002 |
Jan
|
Feb
(11) |
Mar
(9) |
Apr
(32) |
May
(7) |
Jun
(2) |
Jul
|
Aug
(10) |
Sep
(11) |
Oct
|
Nov
(9) |
Dec
(35) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(23) |
Feb
(12) |
Mar
(25) |
Apr
(18) |
May
(52) |
Jun
(55) |
Jul
(10) |
Aug
(5) |
Sep
(6) |
Oct
(16) |
Nov
(9) |
Dec
(19) |
2004 |
Jan
(14) |
Feb
(10) |
Mar
(6) |
Apr
(2) |
May
(7) |
Jun
(3) |
Jul
(3) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2005 |
Jan
(23) |
Feb
(86) |
Mar
(73) |
Apr
(57) |
May
(36) |
Jun
(32) |
Jul
(21) |
Aug
(28) |
Sep
(52) |
Oct
(14) |
Nov
(11) |
Dec
(78) |
2006 |
Jan
(47) |
Feb
(36) |
Mar
(46) |
Apr
(41) |
May
(19) |
Jun
(15) |
Jul
(8) |
Aug
(19) |
Sep
(24) |
Oct
(28) |
Nov
(7) |
Dec
(9) |
2007 |
Jan
(8) |
Feb
(6) |
Mar
(2) |
Apr
(5) |
May
(11) |
Jun
(33) |
Jul
(48) |
Aug
(15) |
Sep
(28) |
Oct
(10) |
Nov
(6) |
Dec
(3) |
2008 |
Jan
(9) |
Feb
|
Mar
(2) |
Apr
(8) |
May
(13) |
Jun
|
Jul
(5) |
Aug
|
Sep
(5) |
Oct
(5) |
Nov
|
Dec
(1) |
2009 |
Jan
(5) |
Feb
(2) |
Mar
|
Apr
(5) |
May
(3) |
Jun
(1) |
Jul
(2) |
Aug
|
Sep
(3) |
Oct
|
Nov
(16) |
Dec
(8) |
2010 |
Jan
(1) |
Feb
|
Mar
(5) |
Apr
(4) |
May
(5) |
Jun
|
Jul
(4) |
Aug
|
Sep
(18) |
Oct
(12) |
Nov
|
Dec
(1) |
2011 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
(1) |
Mar
(28) |
Apr
(11) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(1) |
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
(12) |
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <c....@po...> - 2023-04-27 12:32:33
|
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 |
From: Agron S. <as9...@gm...> - 2022-10-31 18:02:23
|
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 |
From: Daniel L. P. <Dan...@sp...> - 2021-08-13 19:24:16
|
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 |
From: Lauri N. <la...@ik...> - 2021-01-23 21:28:57
|
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 |
From: khamdy s. <kha...@gm...> - 2020-05-30 08:13:43
|
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 |
From: Göran U. <go...@ud...> - 2020-04-28 10:19:20
|
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? |
From: Göran U. <go...@ud...> - 2020-04-28 10:17:28
|
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. |
From: Paul S. <ps...@gn...> - 2020-04-27 16:58:01
|
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. |
From: Lauri N. <la...@ik...> - 2020-04-27 16:08:50
|
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. |
From: Göran U. <go...@ud...> - 2020-04-27 14:28:24
|
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. |
From: Lauri N. <la...@ik...> - 2020-04-27 07:08:00
|
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. |
From: Göran U. <go...@ud...> - 2020-04-21 12:02:59
|
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? |
From: Greta L. S. D'A. <gre...@gm...> - 2019-07-30 00:33:30
|
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 |
From: Krock <mk...@ym...> - 2018-08-22 07:06:32
|
[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 |
From: assaf r. <ass...@gm...> - 2018-08-19 19:18:27
|
What’s this,exactly about? Assaf Rosenkrantz. נשלח מה-iPhone שלי Assaf Rosenkrantz |
From: Bruno H. <br...@cl...> - 2018-08-19 18:48:37
|
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 |
From: Krock <mk...@ym...> - 2018-08-19 15:18:57
|
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 |
From: Alan M. <am...@gm...> - 2017-11-21 00:48:49
|
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 |
From: Alan M. <am...@gm...> - 2017-11-15 03:06:33
|
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 |
From: Bruno H. <br...@cl...> - 2017-11-09 22:07:16
|
[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 |
From: Bruno H. <br...@cl...> - 2017-11-09 19:05:11
|
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 |
From: Alan M. <am...@gm...> - 2017-11-09 01:40:26
|
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 |
From: Bruno H. <br...@cl...> - 2017-11-08 18:13:14
|
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) |
From: Bruno H. <br...@cl...> - 2017-11-08 15:45:41
|
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 |
From: Alan M. <am...@gm...> - 2017-11-08 10:48:52
|
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 |