Menu
▾
▴
dcplusplus-devel
|
From: Michael J. <mrm...@ho...> - 2008-01-17 14:05:57
Attachments:
translations2.rar
|
> All plurals should be translated to TFN_("%1% user online", "%1% users on=
line", n) % n...also, all
> other parametrized strings should be translated to TF_("parameter %1% %2%=
") % value1 % value2...
> See boost format for more detailed formatting information (and check the =
mailing list archives for
> this list). This means that all calls to tformat should go away as well..=
.I'll wait with the patch
> until you get this in order.
Right, this patch is like the last one, but gets rid of all calls to tforma=
t, and as of which i have removed it from Text.h. I also changed my nick in=
a couple of places on this one.
> yes, you need to use the macros based on boost:format. take a look at
> DownloadsFrame.cpp on lines 114 and 116. also i'm not sure about the TFN_
> macro but it seems it's made to handle plurals automatically...
Thanks them examples helped :)
Just want to checking them though, as i not entirely certain of them.
QueueFrame.cpp
- TCHAR buf[64];
if(online> 0) {
if(getSources().size() =3D=3D 1) {
- display->columns[COLUMN_STATUS] =3D TSTRING(WAITING_USER_ONLINE);
+ display->columns[COLUMN_STATUS] =3D T_("Waiting (User online)");
} else {
- _sntprintf(buf, 64, CTSTRING(WAITING_USERS_ONLINE), online, getSourc=
es().size());
- display->columns[COLUMN_STATUS] =3D buf;
+ display->columns[COLUMN_STATUS] =3D str(TF_("Waiting (%1% of %2% use=
rs online)") % online % getSources().size());
}
} else {
if(getSources().size() =3D=3D 0) {
- display->columns[COLUMN_STATUS] =3D TSTRING(NO_USERS_TO_DOWNLOAD_FRO=
M);
+ display->columns[COLUMN_STATUS] =3D T_("No users to download from");
} else if(getSources().size() =3D=3D 1) {
- display->columns[COLUMN_STATUS] =3D TSTRING(USER_OFFLINE);
- } else if(getSources().size() =3D=3D 2) {
- display->columns[COLUMN_STATUS] =3D TSTRING(BOTH_USERS_OFFLINE);
- } else if(getSources().size() =3D=3D 3) {
- display->columns[COLUMN_STATUS] =3D TSTRING(ALL_3_USERS_OFFLINE);
- } else if(getSources().size() =3D=3D 4) {
- display->columns[COLUMN_STATUS] =3D TSTRING(ALL_4_USERS_OFFLINE);
+ display->columns[COLUMN_STATUS] =3D T_("User offline");
} else {
- _sntprintf(buf, 64, CTSTRING(ALL_USERS_OFFLINE), getSources().size()=
);
- display->columns[COLUMN_STATUS] =3D buf;
+ display->columns[COLUMN_STATUS] =3D str(TF_("All %1% users offline")=
% getSources().size());
}
The reason i have left the if =3D=3D 1 in here, and used TF_ for the plural=
part is because off the numbers of arguments after it. Which causes some B=
oost exceptions to be thrown. E.g. in the top one, 0 of the arguments are =
used, but the>1 part uses 2 arguments.
TransferView.cpp
- statusString +=3D Text::tformat(TSTRING(DOWNLOADED_BYTES), pos.c_str(), =
percent, elapsed.c_str());
+ statusString +=3D str(TF_("Downloaded %1% (%|2$.1f|%%) in %3%") % pos % =
percent % elapsed);
- statusString +=3D Text::tformat(TSTRING(UPLOADED_BYTES), pos.c_str(), pe=
rcent, elapsed.c_str());
+ statusString +=3D str(TF_("Uploaded %1% (%|2$.1f|%%) in %3%") % pos % pe=
rcent % elapsed);
Heh, these were a nightmare to get working. :(
I also deleted this, because nothing was using it:
void TransferView::on(UploadManagerListener::Tick, const UploadList& ul) t=
hrow() {
- AutoArray buf(TSTRING(UPLOADED_BYTES).size() + 64);
Directorylistingframe.cpp
- setStatus(STATUS_STATUS, Text::tformat(TSTRING(MATCHED_FILES), matched));
+ setStatus(STATUS_STATUS, str(TFN_("Matched %1% file", "Matched %1% files"=
, matched) % matched));
Searchframe.cpp
- tstring msg =3D Text::tformat(TSTRING(SEARCHING_WAIT), waitFor);
+ tstring msg =3D str(TFN_("Searching too soon, next search in %1% second"=
, "Searching too soon, next search in %1% seconds", waitFor) % waitFor);
=20
thanks
MikeJJ
_________________________________________________________________
Who's friends with who and co-starred in what?
http://www.searchgamesbox.com/celebrityseparation.shtml=
|
|
From: Jacek S. <arn...@gm...> - 2008-01-17 22:36:17
|
> Right, this patch is like the last one, but gets rid of all calls to tformat, and as of which i have removed it from Text.h. I also changed my nick in a couple of places on this one.
Good.
> QueueFrame.cpp
> The reason i have left the if == 1 in here, and used TF_ for the plural part is because off the numbers of arguments after it. Which causes some Boost exceptions to be thrown. E.g. in the top one, 0 of the arguments are used, but the>1 part uses 2 arguments.
Looks good to me...
>
> TransferView.cpp
> Heh, these were a nightmare to get working. :(
As long as they work =)
> I also deleted this, because nothing was using it:
> void TransferView::on(UploadManagerListener::Tick, const UploadList& ul) throw() {
> - AutoArray buf(TSTRING(UPLOADED_BYTES).size() + 64);
good.
I removed some parts of the patch were there were still strings in the form TSTRING(BLAH) + xxx
which should become TF_("Blah %1%") % xxx so that the parameter can be moved...
By my count, there are now approximately 290 strings left (more or less 145 in each of win32 and
dcpp =) and about the same number already done which means that we're at 50% !
/J
|
|
From: Michael J. <mrm...@ho...> - 2008-01-18 14:57:21
|
> I removed some parts of the patch were there were still strings in the fo=
rm TSTRING(BLAH) + xxx
> which should become TF_("Blah %1%") % xxx so that the parameter can be mo=
ved...
Sorted them now.
> By my count, there are now approximately 290 strings left (more or less 1=
45 in each of win32 and
> dcpp =3D) and about the same number already done which means that we're a=
t 50% !
nice, going well then. :)
>> How should CTSTRING(BLAH) end up ?
>CT_ (which is a new macro: "#define CT_(String) T_(String).c_str()")
i didn't realise that this was so new it needed putting in stdafx.h =3D)
And for STRINGS(BLAH) should the T_ macro be used, or a different one ?
Also what macro should be used in the dcpp area ?
Have a few queries for the ones I working on now (still win32):
SearchFrame.cpp:1056
For the search window's title bar which is better ?
setText(T_("Search") + _T(" - ") + T_("Ready to search..."));
setText(T_("Search - Ready to search..."));
Also wasn't sure if the Registry Entries (e.g. for Magnet stuff) in WinUtil=
.cpp should be translatable or not ? Or just some of them.=20
( Especially regarding MAGNET_HANDLER_ROOT which is "DC++" )
This was used in PublicHubFrame, before the cache was introduced. Since no=
thing uses it now, can it be removed, or it want to stay ?=20
#ifdef PORT_ME
double WinUtil::toBytes(TCHAR* aSize) {
blah
Also do the "new"s in SettingsFrame need a corresponding "delete"? Because =
i couldn't see the pages getting deleted anywhere.
There is also a "new" in Util formatTime for non win32 stuff, but i couldn'=
t see any delete for that either.
And last thing, there seems to be a issue with SpyFrame. Open Spyframe and =
just put dc++ in the background for a few minutes and it crashes most the t=
ime. If it doesn't after about 5 mins, clicking the Settings button makes =
it crash. Never get an exceptioninfo or a call stack when ran in debug bui=
ld though. But at least it is reproducible. :)
thanks=20
MikeJJ
_________________________________________________________________
Free games, great prizes - get gaming at Gamesbox.=20
http://www.searchgamesbox.com=
|
|
From: Jacek S. <arn...@gm...> - 2008-01-18 19:34:13
|
> And for STRINGS(BLAH) should the T_ macro be used, or a different one ?
STRINGS?
> Also what macro should be used in the dcpp area ?
same as win32
> SearchFrame.cpp:1056
> For the search window's title bar which is better ?
> setText(T_("Search") + _T(" - ") + T_("Ready to search..."));
> setText(T_("Search - Ready to search..."));
Second option
> Also wasn't sure if the Registry Entries (e.g. for Magnet stuff) in WinUtil.cpp should be translatable or not ? Or just some of them.
> ( Especially regarding MAGNET_HANDLER_ROOT which is "DC++" )
Those that are STRING's should be translated and the others no?
> This was used in PublicHubFrame, before the cache was introduced. Since nothing uses it now, can it be removed, or it want to stay ?
>
> #ifdef PORT_ME
> double WinUtil::toBytes(TCHAR* aSize) {
> blah
Let it be...
>
> Also do the "new"s in SettingsFrame need a corresponding "delete"? Because i couldn't see the pages getting deleted anywhere.
Hm, I think smartwin deletes those, but now that you say it, I'm not so sure...I'll check later on...
> There is also a "new" in Util formatTime for non win32 stuff, but i couldn't see any delete for that either.
AutoArray takes care of that...
> And last thing, there seems to be a issue with SpyFrame. Open Spyframe and just put dc++ in the background for a few minutes and it crashes most the time. If it doesn't after about 5 mins, clicking the Settings button makes it crash. Never get an exceptioninfo or a call stack when ran in debug build though. But at least it is reproducible. :)
Yeah, I've heard about that...tell poy =)
/J
|
|
From: Michael J. <mrm...@ho...> - 2008-01-18 20:11:49
|
> > 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 co=
nverted 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));
=20
> > 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 Uti=
l.cpp use either TSTRING or CTSTRING
e.g.
tstring SourceTypeToDisplayString(SourceType t) { switch(t) { default: =
case OnlyFile: return TSTRING(FILENAME); case OnlyDirectory: return TSTRI=
NG(DIRECTORY); case FullPath: return TSTRING(ADLS_FULL_PATH); } }
=20
So for them wouldn't it be better to use STRING (for now), and let the win3=
2 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.=20
=20
As for this from Util.cpp
_sntprintf(buf, 128, _T("%s %s"), buf, CTSTRING(B));
=20
i've changed it to this on my working copy
_sntprintf(buf, 128, _T("%s %s"), buf, Text::toT(STRING(B)).c_str());
=20
If that's acceptable, and same as moving the ones in ADLSearch that'll leav=
e no TSTRING and CTSTRING in the dcpp area. :)
=20
thanks
MikeJJ
_________________________________________________________________
Get Hotmail on your mobile, text MSN to 63463!
http://mobile.uk.msn.com/pc/mail.aspx=
|
|
From: Jacek S. <arn...@gm...> - 2008-01-18 21:49:07
|
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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X