On Thu, Mar 16, 2017 at 6:41 PM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: > On 3/16/17 10:21 AM, Jan Tulak wrote: >> On Thu, Mar 16, 2017 at 6:02 PM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: >>> On 3/15/17 8:59 AM, Jan Tulak wrote: >>>> Change subopt_param.conflicts from array of integers into array of structures. >>>> This prepares the ground for more universal conflict detection in future >>>> patches. >>>> >>>> Signed-off-by: Jan Tulak <jtulak@xxxxxxxxxx> >>>> --- >>>> mkfs/xfs_mkfs.c | 243 ++++++++++++++++++++++++++++++-------------------------- >>>> 1 file changed, 129 insertions(+), 114 deletions(-) >>>> >>>> diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c >>>> index 5e15fee2..c9861409 100644 >>>> --- a/mkfs/xfs_mkfs.c >>>> +++ b/mkfs/xfs_mkfs.c >>>> @@ -93,8 +93,16 @@ unsigned int sectorsize; >>>> * >>>> * conflicts MANDATORY >>>> * If your subopt is in a conflict with some other option, specify it. >>>> - * Accepts the .index values of the conflicting subopts and the last >>>> - * member of this list has to be LAST_CONFLICT. >>>> + * Accepts the .index values of the conflicting subopt as .opt (e.g. OPT_D) >>>> + * and .subopt (e.g. D_FILE). If .test_values is true, then the conflict >>>> + * is raised only when the "remote" suboption .value is equal to >>>> + * .invalid_value field and the "current" suboption has .value equal to >>>> + * .at_value. >>>> + * If .test_values is false, a conflict is raised when the suboption appears >>>> + * on the CLI, no matter its value. The field .message contains an optional >>>> + * explanatory string for the user. This string can't be translated here, >>>> + * so it has to be enveloped with _() when printed. >>> >>> You also still need to mark each string initializer you added in the array >>> in patch 08 with N_(" ... ") or gettext won't know about it. >>> (I think that's the right way to go about it) >>> >>> -Eric >> >> See patch 06, the last chunk. It adds printing of the error with >> "_(conflict->message)". > > yes, but nothing tags the actual conflict strings as needing translation. > > https://www.gnu.org/software/gettext/manual/html_node/Special-cases.html#Special-cases > > might help. > > note that we use macros - N_() is gettext_noop(), and _() is gettext() > >> So if C gettext is a function evaluated on the run and not a macro >> evaluated on the compile time, then it should be ok. (And everywhere I >> looked, I saw it mentioned as a function... Although I admit I didn't >> tested it.) > > Well, give it a test. If it works, fine, but I do not see these strings > ending up in the .pot file so I'm skeptical. > > -Eric Ah, it makes sense this way - the translation works, but the new strings are not marked without the _() or N_(). Jan -- Jan Tulak jtulak@xxxxxxxxxx / jan@xxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html