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
prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox