Re: [PATCH 0/13] xfs_repair: recombine cut&waste code in dir2.c/attr_repair.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 09, 2015 at 02:33:58PM -0500, Eric Sandeen wrote:
> repair/dir2.c and repair/attr_repair.c got cut and pasted
> long, long ago and have diverged since.
> 
> This series brings them back together, presumably fixes some
> bugs, and loses a few hundred lines in the process.
> 
> o/~ reunited, and it feels so so good ... o/~
> 
> The series accomplishes this through a combination of trivial changes
> (removing unused structure members, whitespace, etc) as well
> as by "cross-porting" changes & fixes which happened to one
> file but not the other over the past many years.
> 
> Along the way, a graphical diff of dir2 vs. attr_repair should
> show the convergence.
> 
> Up until the last patch, I don't worry about dir vs. attr naming
> in comments or error messages; the goal is to make these chunks
> of the two files sufficiently similar so that by patch 11, the
> reviewer can do a diff and say "yeah, ok, those really are
> substantially the same now."
> 
> Also instructive is to apply up to patch 11, copy dir2.c and
> attr_repair.c to /tmp, apply patch 12, and do a 3-way graphical
> diff of the 3 files to see that the move really is OK and
> didn't play any significant tricks.
> 
> 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.

>
> because that's essentially the trick I used...
> 
> Thanks,
> -Eric
> 
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs

-- 
Carlos

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



[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux