Re: Emacs i18n

["Mattias Engdegård" <mattiase@acm.org>]

24 mars 2019 kl. 22.55 skrev Juri Linkov <juri@linkov.net>:
> 
> http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00586.html
> is pushed to master, ngettext is available to use for pluralization.

That patch exposes some Emacs-specific translation problems:

-                 (cons (format "finished with %d matches found\n" 
grep-num-matches-found)
+                 (cons (format (ngettext "finished with %d match found\n"
+                                         "finished with %d matches found\n"
+                                         grep-num-matches-found)
+                               grep-num-matches-found)

This is fine -- typical i18n code (except that the subject of the sentence is missing, which should go into a comment to translators).

      ;; remove match from grep-regexp-alist before fontifying
      ("^Grep[/a-zA-Z]* started.*"
       (0 '(face nil compilation-message nil help-echo nil mouse-face nil) t))
-     ("^Grep[/a-zA-Z]* finished with \\(?:\\(\\(?:[0-9]+ \\)?matches 
found\\)\\|\\(no matches found\\)\\).*"
+     ("^Grep[/a-zA-Z]* finished with \\(?:\\(\\(?:[0-9]+ \\)?match\\(?:es\\)? 
found\\)\\|\\(no matches found\\)\\).*"

Since it is not uncommon in Emacs to pattern-match on generated text, either the translator needs to understand regexps well or the code must be restructured to avoid that kind of matching, perhaps by using text properties. Besides, translating regexp strings precludes the use of modern regexp notations like rx, since gettext is string-oriented.

Of course the patch was just a proof-of-concept and not intended as actual code. Please forgive me for using it to make a point.

This is also not an argument against using gettext. Quite the contrary; it's the obvious way to go if i18n is to be undertaken at all.