All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carlos Maiolino <cmaiolino@redhat.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 0/13] xfs_repair: recombine cut&waste code in dir2.c/attr_repair.c
Date: Fri, 11 Sep 2015 10:20:20 +0200	[thread overview]
Message-ID: <20150911082020.GA2523@zion.usersys.redhat.com> (raw)
In-Reply-To: <55F1B4FC.5040207@sandeen.net>

On Thu, Sep 10, 2015 at 11:51:08AM -0500, Eric Sandeen wrote:
> On 9/10/15 4:22 AM, Carlos Maiolino wrote:
> > On Wed, Sep 09, 2015 at 02:33:58PM -0500, Eric Sandeen wrote:
> 
> ...
> 
> >> The last patch fixes up the dir vs. attr text in error messages
> >> and comments.  I do have a question about whether this is ok
> >> for i8n:
> >>
> >> 	printf(_("This string is %s"), _("awesome"));
> > 
> > This should be fine for i18n, I had used it a lot when I added i18n support in
> > gfs2-utils, and _() is the default macro that should embrace every string that
> > needs to be translated. It will be replaced by gettext("awesome"), and there is
> > no problem in using it as printf() argument for format specifiers.
> > 
> > What you should be careful though, is that how these strings will 'look' to the
> > person translating it, which, in most of cases, they are not going to look at
> > the code to get a better meaning of the string. So, the sentences to be
> > translated, should make sense by itself.
> > 
> > 
> > I particularly, don't like much the idea of split strings as you did in the
> > example, exactly because how it might look to the translators, both strings
> > makes the same sentence, but they will show to the translators as completely
> > different strings, and the translator might not be able to find the proper
> > grammatical construction. So, I'd do something like:
> > 
> > printf(funny ? _("This string is awesome") : _("This string is boring")) 
> > 
> > 
> > I know that I might sound picky here, but, this is the best way to avoid weird
> > and non-sense string translations.
> 
> No, that makes sense, but it kind of sucks, too - writing the same string

> twice everywhere, once for attr & once for dir, is a bit bleah.
> 
> Maybe I can restructure it such that it's more easily translatable,
> something like using a prefix, i.e.
> 
> %s: block %d is unreadable for inode %lld
> 
> -> turns into ->
> 
> dir: block %d is unreadable for inode %lld
>  - or -
> attr: block %d is unreadable for inode %lld
> 
> and then it's not cutting a sentence in half, to interfere with grammar
> from other languages ...
> 

Yep, that makes sense. Or, you can play with variables, but, that would make the
code only a huge spaghetti of strings and probably nobody would want to see
things like that.


> -Eric
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

-- 
Carlos

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

      reply	other threads:[~2015-09-11  8:20 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-09 19:33 [PATCH 0/13] xfs_repair: recombine cut&waste code in dir2.c/attr_repair.c Eric Sandeen
2015-09-09 19:33 ` [PATCH 01/13] xfs_repair: remove trace-only 'n' member from da_level_state Eric Sandeen
2015-09-14 19:17   ` Brian Foster
2015-09-09 19:34 ` [PATCH 02/13] xfs_repair: remove type from da & dir2 cursors Eric Sandeen
2015-09-14 19:18   ` Brian Foster
2015-09-09 19:34 ` [PATCH 03/13] xfs_repair: make CRC checking consistent in path verification Eric Sandeen
2015-09-14 19:18   ` Brian Foster
2015-09-09 19:34 ` [PATCH 04/13] xfs_repair: use multibuffer read routines in attr_repair.c Eric Sandeen
2015-09-14 19:18   ` Brian Foster
2015-09-14 19:24     ` Eric Sandeen
2015-09-14 19:30       ` Brian Foster
2015-09-09 19:34 ` [PATCH 05/13] xfs_repair: fix use-after-free in verify_final_dir2_path Eric Sandeen
2015-09-14 19:18   ` Brian Foster
2015-09-09 19:34 ` [PATCH 06/13] xfs_repair: add XR_DIR_TRACE to dir2.c Eric Sandeen
2015-09-14 19:18   ` Brian Foster
2015-09-09 19:34 ` [PATCH 07/13] xfs_repair: Remove BUF_PTR from attr_repair.c Eric Sandeen
2015-09-14 19:44   ` Brian Foster
2015-09-09 19:34 ` [PATCH 08/13] xfs_repair: catch bad level/depth in da node Eric Sandeen
2015-09-14 19:44   ` Brian Foster
2015-09-09 19:34 ` [PATCH 09/13] xfs_repair: better checking of v5 attributes Eric Sandeen
2015-09-14 19:44   ` Brian Foster
2015-09-23 17:53     ` Eric Sandeen
2015-09-09 19:34 ` [PATCH 10/13] xfs_repair: Remove more differences between attr & dir2 Eric Sandeen
2015-09-14 19:55   ` Brian Foster
2015-09-09 19:34 ` [PATCH 11/13] xfs_repair: whitespace & comments Eric Sandeen
2015-09-14 19:56   ` Brian Foster
2015-09-09 19:34 ` [PATCH 12/13] xfs_repair: move common dir2 and attr_repair code to da_util.c Eric Sandeen
2015-09-09 19:34 ` [PATCH 13/13] xfs_repair: Fix up warning strings in da_util.c Eric Sandeen
2015-09-14 20:06   ` Brian Foster
2015-09-14 20:11     ` Eric Sandeen
2015-09-10  9:22 ` [PATCH 0/13] xfs_repair: recombine cut&waste code in dir2.c/attr_repair.c Carlos Maiolino
2015-09-10 16:51   ` Eric Sandeen
2015-09-11  8:20     ` Carlos Maiolino [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150911082020.GA2523@zion.usersys.redhat.com \
    --to=cmaiolino@redhat.com \
    --cc=sandeen@sandeen.net \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.