Re: [dcplusplus-devel] Some more translations again

[Jacek S. <arn...@gm...>]

Michael Jones wrote:
>> > And for STRINGS(BLAH) should the T_ macro be used, or a different one ?
>> STRINGS?
> Sorry my bad, STRING(BLAH), looking though most end up getting converted
> via Text::toT anyway so i've used the T_ macro for them.
> Some don't though mainly in HubFrame.cpp, e.g.
>   speak(ADD_STATUS_LINE, STRING(REDIRECT_ALREADY_CONNECTED));
STRING simply becomes _(BLAH) (the same goes for the others - no T before, no T now...)
Although as you say, if they end up being converted anyway, you might as well use T_...


>> > Also what macro should be used in the dcpp area ?
>> same as win32
> Okay, just that most in dcpp use STRING, only 7 in ADLSearch.h and 1 in
> Util.cpp use either TSTRING or CTSTRING
See above...

> e.g.
>  tstring SourceTypeToDisplayString(SourceType t) {
>   switch(t) {
>   default:
>   case OnlyFile:  return TSTRING(FILENAME);
>   case OnlyDirectory: return TSTRING(DIRECTORY);
>   case FullPath:  return TSTRING(ADLS_FULL_PATH);
>   }
>  }
>  
> So for them wouldn't it be better to use STRING (for now), and let the
> win32 area deal with converting them to a tstring ?
> Since they are getting converted to a "DisplayString" i would have
> thought that's win32's job.
I don't have a strong opinion in either direction...

> As for this from Util.cpp
>   _sntprintf(buf, 128, _T("%s %s"), buf, CTSTRING(B));
>  
> i've changed it to this on my working copy
>   _sntprintf(buf, 128, _T("%s %s"), buf, Text::toT(STRING(B)).c_str());
F_("%1% b") % buf ?

> If that's acceptable, and same as moving the ones in ADLSearch that'll
> leave no TSTRING and CTSTRING in the dcpp area. :)
fine by me..

/J