[翻译进行中]wxWidgets C++ Users Forum FAQ

这是wxWidgets论坛的中文版本。在这里,您可以用您的母语汉语讨论上面任一子论坛所涉及的所有关于wxWidgets的话题。欢迎大家参与到对有价值的帖子的中英互译工作中来!
Utensil
Moderator
Moderator
Posts: 423
Joined: Sun Feb 03, 2008 11:38 am
Location: China

[翻译进行中]wxWidgets C++ Users Forum FAQ

Postby Utensil » Fri Mar 07, 2008 11:47 am

征求志愿者翻译

wxWidgets C++ Users Forum FAQ
http://forums.wxwidgets.org/viewtopic.php?t=82
由Ryan Norton整理的论坛里常见问题,由多张帖子组成。


有关志愿者翻译事务,请参见 对wx论坛的中文版块的展望

谢谢您的支持与参与! :)
Last edited by Utensil on Mon Jun 30, 2008 5:56 am, edited 1 time in total.
In fascination of creating worlds by words, and in pursuit of words behind the world.

On Github: http://utensil.github.com
Technical Blog in Chinese: http://utensil.iteye.com/

swordfish862
In need of some credit
In need of some credit
Posts: 6
Joined: Mon Apr 07, 2008 12:06 pm
Location: Yunnan,China
Contact:

Postby swordfish862 » Mon Apr 07, 2008 2:15 pm

一、常规FAQ

1、什么是wxWidgets?
wxWidgets是一个类库,可以用来在多种平台(操作系统)下编译图形化C++程序。
wxWidgets定义了一(组)跨平台通用API,却在每个平台下使用了(该平台的)本地图形用户接口(GUI),使得你的程序“看上去感觉”就是用户熟悉的本地(程序)。大多数GUI应用程序都是用(对话框开发)程序所构建,有几个对话框编辑程序可以构建漂亮的对话框和面板。除了Rober Roebling的wxDesigner和Anthemion软件(公司)的DialogBlocks两个有代表性的商业(对话框编辑程序)之外,还有其他的几个,(详情)参阅wxCommunity页面。
为了使用wxWidgets,并不一定非要使用C++,wxWidgets还有Python(语言)和Perl(语言)接口。
(翻译功底薄弱,请楼主斧正)

swordfish862
In need of some credit
In need of some credit
Posts: 6
Joined: Mon Apr 07, 2008 12:06 pm
Location: Yunnan,China
Contact:

Postby swordfish862 » Mon Apr 07, 2008 2:34 pm

2、我能在商业项目和GPL项目中使用wxWidgets吗?
是的。请参阅licence(许可证)获取详情。基本上,你可以发布(使用了wxWidgets的)商业可执行文件而不用发布任何源代码。而且wxWidgets(的许可证)不和你所使用或是开发的GPL代码(的许可证)相矛盾。
无论个人、大学生或是商业开发者使用wxWidgets的条款都是一致的。

liuqi5521
Earned some good credits
Earned some good credits
Posts: 103
Joined: Thu Apr 03, 2008 5:35 am
Location: China
Contact:

Postby liuqi5521 » Thu Jun 12, 2008 7:04 am

常规FAQ

三、 有技术支持吗?

没有官方的技术支持, 但是邮件列表可以给你很大帮助,很多人都说wxWidgets 的技术支持比很多商业软件都好.很明显,虽然没有任何担保,但wxWidgets 的开发者们都是非常热心的以最快的速度修复Bug。

四、谁使用wxwidgets ?

许多组织-世界各地的商业机构,政府和学府。因为可以有很多不同的途径来获得wxwidgets,我们不能监测分布状况,所以无法估计真正的用户数量。

参见用户页,列出了一些用户和他们写的应用程序,还有反馈页面,有一些评论。

我们的资历最高的用户,是业界资深的、Lotus公司的创建人Mitch Kapor和他的Open Source Applications Foundation.


五、wxWidgets 都支持哪些操作系统平台?
Windows 95/98/ME, NT, 2000, XP, and Vista.
Linux 和其他包含 GTK+ 的 Unix 平台.
包含 Motif 或 较少的Motif免费克隆版 的 Unix.
Mac OS X 10.3 和更高的版本 (10.2 和2.6版本(应该是指wxWidgets) ).
嵌入式平台的支持情况正在研究, 参考 [url=http://wxwidgets.org/about/wxuniv.htm]wxUniversal 工程.
[/url]
支持OS/2 的接口正在开发完善中, 你也可以把 wxWidgets 针对 OS/2上的GTK+或Motif 进行编译.


六、
wxWidgets 通过什么方式支持平台独有的特性?

这是开发者之间争论很激烈的一个论题. 我自己的观点是: 尽可能的保证它(wxWidgets)的平台无关性, 但是允许少数的类(函数、窗口样式)是某些平台所独有的. 比如,在windows平台上,图元文件和任务栏图标有它们自有的类, 其他平台就没有这些类. 因为这些类已被提供并且兼容于wxWidgets, 编写应用程序的程序员添加对某些功能的支持是非常容易的,不需要在编码上花费太多努力,但是其他平台下却不是这样. 此外, 一些由于平台特性而产生的类, 比如与 MDI 有关的那些类, 在其他平台上已经有了仿真的实现. 我可以想象在某一天,连 wxTaskBarIcon 这样的类都可能会在 Unix 桌面版上面实现.

换言之, wxwidgets 不是按照"最低共同特征"设计的,但使用核心API仍可以写出可移植的代码。禁用那些平台特有的类是一个愚蠢的做法,这将会失去许多潜在用户,并且会引起这么一种感觉:象wxWidgets这类的工具包是达不到今天设计日益复杂的应用程序的要求的。

目前,象位图、图标这类的资源都是用具体平台特有的的方式处理的,但是我们都希望用适当的手段去减少这种平台依赖。

wxwidgets不是'最低共同特征'工具包的另一个原因是:针对在某些平台下没有的功能,已提供通用的、独立于平台的代码,如wxtreectrl和wxlistctrl类。


wxWidgets使用了STL(标准模板库)、标准的字符串类了吗?


没有。这是一个广为讨论的话题,这个话题(不止一次的)得出了最终结论:避免使用模板对wxWidgets来说是最有利的方式。并不是所有的编译器都可以充分的支持模板,因此(如果使用模板的话)将会大大的减少wxWidgets可以支持的编译器和平台。同时,使wxWidgets依赖于另一个大型的类库,并且需要另外的下载和安装这个类库,是不可取的。此外,使用模板将使可执行程序体积变大,而这正是wxWidgets所极力避免的事情。

标准的C++字符串类也没有使用,原因是并非所有的编译器都支持它,并且它也未必是一个非常高效的实现(字符串的)方式。同时,我们能够修改我们自己的字符串类,这样就可以有更大的灵活性。与标准字符串类的一些兼容性已经被加入wxString中。

这并不妨碍应用程序为了完成自己的目标而使用模板和标准字符串类。在wxWidgets的调试开关打开的情况下,如果包含了STL的头文件,你可能会发现编译有错误。你可以通过关掉内存检测,或是在包含STL的头文件之前把如下内容添加到一个头文件里来通过编译:

#ifdef new
#undef new
#endif


wxWidgets(框架)里面是否有丰富文本编辑、标记的控件?


目前来说(实现你的目的)是可能的:

*请参考:http://www.scintilla.org ,这里有一个非常好的语法突出显示的文本框组件。罗宾邓恩为这个组件写了一个wxWidgets封装,你可在wxWidgets 的发布中找到,在contrib/src/stc路径下。
*如果你仅仅是需要显示带有标记的信息,而并不需要编辑它,那么wxHTML可以满足你的要求。wxHTML内建在wxWidgets框架里,请参阅参考手册里的详细介绍,和samples/html路径下的例子程序。
*其实Win32和GTK+都有RichEdit组件,但是目前还没有对应的wxWidgets封装(但是文本框的属性函数正在被添加进 wxWidgets 2.3.x 系列中)。


wxWidgets编程中怎么使用C++的异常处理?


很遗憾的是wxWidgets库本身不是“异常安全”的(因为wxWidgets的最初版本的出现远远的早于C++语言添加异常机制的时间)。然而在你自己的代码中仍然可以使用异常机制,并且可以使用其他用异常机制来报告错误的库和wxWidgets协同工作。

然而,有几个问题是要记住的:

* 你不能让“异常”传递到wxWidgets的代码中,尤其是,你应该捕获这样的异常:被事件处理函数调用的函数抛出的异常,你应该在事件处理函数内部就捕获它,这样才能避免“异常”被向上传递到wxWidgets的代码中。

(个人注解:如果在一个函数中异常没有被捕获,那么异常是沿着函数调用栈一直向上传递的,直到被捕获、处理为止,如果整个栈都没有捕获,那么要传递给系统的全局异常处理函数来处理。)

*考虑到wxWidgets本身不使用异常处理机制而且开启了编译器对异常处理机制的支持将会使库的编译后体积膨胀10%至20%,因此少数编译器本身默认是不打开对异常处理机制的支持的,这就需要你去手动的打开这个开关来保证你能够处理异常。此外,对于gcc编译器(或者至少是mingw版本),你必须开启RTTI(Run-Time Type Identification运行时类型识别)以保证你能够使用异常处理,所以当你配置库的时候你需要这样配置: --disable-no_rtti --disable-no_exceptions (注意,这是双重否定)。


wxWidgets是怎样开发的?

我们使用SVN系统来开发和维护wxWidgets。这个系统允许我们修改代码并且及时的把修改后的代码上传到服务器上,其他人可以通过这个服务

器来升级他们的wxWidgets源代码。

想要编译从SVN获得的代码,请参考wxWidgets的发布目录的根目录下的BuildSVN.txt。

十一
wxWidgets是怎样发布的?


你可以从我们的下载页面下载wxWidgets。如果大胆一些,你可以直接从SVN上获取源代码。

十二
wxBase是什么?


wxBase是由无界面的类组成的一个wxWidgets子集。它包括wxWidgets的容器和基本数据类型类(包括wxString,wxDateTime等等),还有对操作系

统的有效封装,比如文件处理,进程,线程,套接字等等。除了少数例外的情况,wxBase和wxWidgets的基本用法是一样的,但是wxBase的运行

不要求GUI,所以用来创建控制台方式或服务器程序是一个理想的选择。创建一个可同时编译为控制台应用程序(使用wxBase)或图形界面应用

程序(用包含全部特性的wxWidgets接口)的程序也是可以做到的。

十三
wxUniversal是什么?

基于wxUniversal的接口和其它接口(像wxMSW,wxGTK+,wxMac)的主要区别在于:wxUniversal自身实现了 wxWidgets 的所有控件,这就提供了

更多了灵活性(比如,甚至在MS Windows下支持主题)。
这同时也意味着现在要把wxWidgets移植到一个新的平台上要容易多了,因为只须移植那些底层的类,而它们只占wxWidgets类库的很小一部分。

你可以从这里得到wxUniversal的更多信息。

十四
Java怎么样?

Java已经降温了 :-) 人们逐渐意识到,它不能满足所有的跨平台开发的需要。
我们并不认为Java 将来会是一个主要威胁,人们对wxwidgets感兴趣的程度比以往任何时候都高。


十五
.NET/Mono怎么样?

微软为推动 .NET 的发展花了很大力量,.NET是编程语言、API、网络服务组件的集合。Ximian 开发了一个开源版本的.NET,主要是用在linux 下。C#是微软推出与java 竞争的产品,它在很多方面类似于java,比如“托管代码”、“垃圾回收机制”等等。

以上这些特性也许会对开发者有很大吸引力。但是绝不会因为有.NET/Mono的存在,就使wxWidgets失去了存在的价值。请留意一下下面这些观点,出自Julian的独到见解:

1 并不是所有的人都需要网络服务。
2 在未来很长一段时期内,C++仍将会广泛的应用。和C++比起来,C#是最近才发展起来的,并且前景也不明朗。
3 Mono表单只能够用在Winelib上面(至少开始是这样),这得到的结果肯定不如原生代码的wxWidgets。(据我所知,有使用C#语言的GTK#)
4 C#通常是字节编译,因此运行的更慢。另外,.NET需要客户端上有一个解释层(指.NET框架),wxWidgets不需要。
5 Mono还没有证明其有长久的生命力(这是一个复杂的组件系统)。WxWidgets则已经证明了。
6 你不希望被微软的市场战略和API牵着鼻子走。
7 微软可能随时因为.NET的非微软的实现而去起诉开发商/开发者。毕竟,跨平台其实不符合微软的利益。
8 .NET也许永远不会在某些平台上实现,比如Mac、Linux的嵌入式版本。
9 wxPython和其他的变体都是wxWidgets继续发展下去的理由。
10 Qt也面临着同样的问题:只要Qt的销售势头仍然很好,那就说明,C++开发阵营仍然占有一席之地。(如果Qt不流行了,大家转到wxWidgets来吧 :-)

没有什么会阻碍民间自发的开发wxWidgets API的C#版本。现在,我们已经绑定了Python、Perl、JavaScript、Lua、Basic、Eiffel语言。更新:一个wx.NET项目现在正在进行中。

十六
我怎么才能够为wxWidgets贡献自己的力量?


请查看开发者社区, 特别是suggested projects,你可以把自己的意见、好的建议发到邮件列表上去.

十七
我怎么开发一个新的接口?

请订阅开发者邮件列表(wx-dev),并询问有没有人对开发这个接口感兴趣,或者是有一些特别的建议也行。你也需要看看代码编写规范

每一个接口都由三部分组成:1、平台相关部分(例如:src/msw , include/wx/msw);2、一些控件、对话框的集合 (src/generic, include/wx/generic),接口不是以原生的方式支持他们;3、所有接口都使用的公用代码(src/common, include/wx)。通过浏览这些代码,你会对整体的架构有深入的理解。

找一个和你要定义的接口最接近的现有接口,剥离出实现代码,编译得到一个框架。先在wx-dev上面获得wxStubs接口。当然,象这类预定义的框架接口可能已经过期,所以需要你做出判断来决定是否使用它。先整理一下wxStubs,可能接下来会更省时,其他的工作可能也会附带收益的。

你需要为新的接口定义一个标识符,例如 __WXXBOX__ 。参考象 wx/defs.h, wx/wxchar.h 这类的文件,你可以知道在哪里添加条件编译指令来支持宽字符集编译和其他问题。如果GUI(图形用户界面)运行在Unix的变体版,请在makefile中定义 __UNIX__ 变量。

接下来你就可以实现你的新接口的代码了,在wxWindow, wxTopLevelWindow, wxFrame, wxDialog 的基础上,很快就可以创建出你的小型示例程序。

如果在你的本地平台上有GDI对象(wxPen, wxBrush, etc.) 不被支持,那么你可能希望去使用他们的通用版本,参考 wxX11 接口。

可以考虑使用wxUniversal控件集来加快在你的平台上实现控件的开发速度。你只需要定义一些基本的类,就像是 device contexts, wxWindow, wxTopLevelWindow, GDI objects 等等,然后实际的控件就会自动的绘制出来。参考wxUniversal 接口中的 wxX11,wxMGL, 和 wxMSW/Univ。

开始的时候,你可以随便找makefile或者工程文件来用。可以参考现成的makefile,来看看generic/common/Unix 里的哪些文件需要囊括在内。然后,你需要把对你的接口的支持整合在配置文件 (Unix系的系统和Windows下的gcc)和bakefile中(for other makefiles on Windows)。

通过SourceForge,把你的编写的接口作为一个补丁提交上去。你可以把它分割成两个部分:一个是提供公共的头文件和源代码的包,另外的一个则包含接口专有的代码,这样做使得我们去看代码、使用这些包都会变得更容易一些。

Good luck!
Last edited by liuqi5521 on Thu Jul 24, 2008 3:56 am, edited 13 times in total.

00061205
Knows some wx things
Knows some wx things
Posts: 41
Joined: Mon Jun 16, 2008 3:43 am
Location: Beijing, China

常规FAQ

Postby 00061205 » Wed Jun 18, 2008 4:34 am

问:我编译OpenGL/GLCanvas的例子时总是报错,让我把wxUSE_GLCANVAS编程1。我在setup.h里改了后就得到一堆链接错误。
答:首先确定你setup.h文件里的wxUSE_GLCANVAS值是1,然后在编译时包含opengl32.lib和glu.lib这两个库文件。

问:和MFC里面VERIFY宏等价的wxWidget宏是什么?
答:没有,但wxCHECK的功能很接近,下面的代码是一种解决方法。

Code: Select all

#ifdef _DEBUG
#define wxVERIFY(cmd) \
    wxASSERT((cmd))
#else
#define wxVERIFY(cmd) \
    (cmd)
#endif


问:为什么我不能在wxButton(派生自wxWindow类)里添加wxPanel或sizer?
答:因为大多数系统API不支持,而wxWidgets需要用系统API来实现。解决这个问题的方法是不使wxButton派生自其他类,而是自己照看全部代码。或者用wxUniversal,它只依赖于系统API做简单的事情

Utensil
Moderator
Moderator
Posts: 423
Joined: Sun Feb 03, 2008 11:38 am
Location: China

Postby Utensil » Mon Jun 30, 2008 5:47 am

谢谢swordfish862、00061205、liuqi5521的翻译~=D>

liuqi5521 wrote:It also means that it is now much easier to port wxWidgets to a new platform as only the low-level classes must be ported

which make for a small part of the library. (这句没有理解!请高手们出马)


我译为:
这同时也意味着现在要把wxWidgets移植到一个新的平台上要容易多了,因为只须移植那些底层的类,而它们只占wxWidgets类库的很小一部分。


是什么地方不能不能理解?
In fascination of creating worlds by words, and in pursuit of words behind the world.

On Github: http://utensil.github.com
Technical Blog in Chinese: http://utensil.iteye.com/

liuqi5521
Earned some good credits
Earned some good credits
Posts: 103
Joined: Thu Apr 03, 2008 5:35 am
Location: China
Contact:

Postby liuqi5521 » Sun Jul 06, 2008 9:27 am

哦,我在翻译 “十三 wxUniversal是什么?”的时候,
一直把单词 port 理解成是端口、接口的意思,所以怎么也理解不了整句话,版主把 port 翻译为移植就通顺了。已经把这句正确的翻译改到帖子里面了。

HeMason
Experienced Solver
Experienced Solver
Posts: 73
Joined: Tue Jun 30, 2009 10:07 am
Location: Taiwan
Contact:

翻譯工作的淺見

Postby HeMason » Tue Aug 18, 2009 3:00 am

感謝翻譯的前輩們!給我們後學提供了方便的學習。

小弟的程度還是初學,不敢貿然翻譯,但可以提供一些文字上的見解。
不是想雞蛋裡挑骨頭,實在因為這裡翻譯出來的內容,有承先啟後的地位,所以要是能更為「信、達、雅」,那就是後學之福了!

以下提出一些討論:

● Interface

GUI 翻成「圖形使用者接口」,不禁讓小弟生起疑問,到底 Interface要怎麼翻比較好?因為下面的翻譯內容一直出現「接口」一詞,所以小弟想提出討論一下。

查了一下 wiki上的翻譯:
http://zh.wikipedia.org/wiki/GUI

他翻成「界面」,這和台灣翻法是一致的。

● User

至於User翻成「用戶」、「使用者」,似乎都可以。
但是個人比較傾向於「使用者」。

● Wiki 的參考

小弟有個建議,是否一些專有名詞在翻譯前,先查一下wiki怎麼翻。
要是翻起來還是拗口,乾脆留下原詞,可能還比較不會產生誤解。

● 五不翻

中國古代翻譯佛經時,有所謂的「五不翻」原則,個人認為非常值得參考:
也就是「祕密、含多義、此方無、順於古、為生善」。

● Class -> 「類 or 類別」二字詞優先的原則

例如 Class 單翻為「類」一個字,在前後文相接時,很容易會因為「接詞」而誤解。因為「單字詞」是比較難被解讀的,要是翻成「類別」,那大腦在「斷詞」時,就不會產生混淆。大腦對於「二字詞」會更容易辨認,因為名詞幾乎都是「二字詞」。

● 宏?

小弟乍看下面這一段:
问:和MFC里面VERIFY宏等价的wxWidget宏是什么?

沒有看到原文時,還真是一頭霧水!
「VERIFY宏、wxWidget宏」是怎麼回事?
一看原文,原來是 macro!
查了一下 wiki,真的就翻作「宏」!
但是有說「港台称为巨集」。
或許是大陸同胞看習慣了,所以沒有很大的問題,但因為是「單字詞」,大腦很難融通。

要是譯文為:
MFC里面VERIFY宏大可寫為下列方式:
「宏」和「大可」造成搶詞現象,大腦就會混淆。

如果是二字詞:
MFC里面VERIFY巨集大可寫為下列方式:
您看,不搶詞了!您一定會把「大可」連在一起。
不會把「宏大」連成一詞。

假如我們創造一個叫「宏碼」的假想翻譯,您再試看看:
MFC里面VERIFY宏碼大可寫為下列方式:
是不是也很達意?

末學所學粗淺,沒有任何貶抑的意思,拙見僅供前輩們參考!
「漢書文書處理系統」作者,在這向大家學習。
MyBlog 梅僧山房

Utensil
Moderator
Moderator
Posts: 423
Joined: Sun Feb 03, 2008 11:38 am
Location: China

Postby Utensil » Thu Aug 20, 2009 8:02 am

HeMason您好:

您文中所述各处,多为大陆和台湾译法常见之别。小弟在初遇台湾译法时,也曾糊涂和不以为然,其实是两岸翻译历史积淀下来的极其迥异的翻译习惯和阅读习惯。侯捷先生曾在《Word排版艺术》一书中提及此别,还专门做了VBA宏来对两岸常见不同译法做转换。

不同翻译间可读性的差异,在完全不同的两个读者群体面前,就很难以理去论证某一翻译的可读性。这就使得小弟对您文中表达的语感自然地会不认同。

一部分已积淀在大陆出版物中的稳定译法包括:

GUI 图形用户界面

但单独的interface,则多译为接口,如API

class 类

类别有自己的意思,语感与class不符,更适合用在翻catagory之类的词
(记得侯捷先生专门将此译为“型别”,虽然更为恰当地表达class在C++中的内涵,读起来小弟却感觉很拗口)

macro 宏

巨集一词,若无专门介绍,在大陆读者看来,实在难以理解。

文中您提到参考wiki,中文wiki有一点非常好,它专门为两岸译法不同有自动转换,且看

http://zh.wikipedia.org/wiki/API

点选“大陆简体”,interface变为接口,点选“台湾正体”中则为界面。

您提到名词多为双词,单字词容易抢词。这一点小弟不敢苟同,还有些慨叹。

您来自台湾,传统文化传承远胜大陆。而古文之中,言简意赅,名词多为单字词,双字词甚少。纵然有形如现代的双字词,其实却是两个单字词,其中意蕴丰富,在现代汉语(大陆的语境下)已经部分丧失或弱化,合并为双字词。

小弟少时学古文,最爱就是单字词,自己的散文中,也喜欢用单字词,或在双字词中藏入两个单字词。

以上算是一个个人的偏好,而在“类”和“宏”这两个案例中,则因为是大陆固定译法,阅读习惯上没有那么容易抢词。

小弟拙见,还请前辈指教~(从年龄和资历上,您无论如何都算是小弟的前辈的,对于这里许多人,都是如此。您的自谦和涵养,值得我们学习。)

Regards,

Utensil
In fascination of creating worlds by words, and in pursuit of words behind the world.

On Github: http://utensil.github.com
Technical Blog in Chinese: http://utensil.iteye.com/

HeMason
Experienced Solver
Experienced Solver
Posts: 73
Joined: Tue Jun 30, 2009 10:07 am
Location: Taiwan
Contact:

感謝翻譯志工辛苦的付出

Postby HeMason » Thu Aug 20, 2009 8:28 am

感謝 Utensil 的指教!

小弟對兩岸文化差異,實在沒有很多體認,上文建議純粹是一己的妄想。
這些當然只是建議而已,希望對翻譯前輩們不要產生誤導才好。

小弟受益於這個論壇,是想有機會時可以回饋一下,或許幫忙翻個幾段。
但是想到翻出來後,可能大家反而看不懂,所以我看算了,還是不要現醜得好,呵呵呵~

年輕時,小弟和內人倒是翻了很多資訊電腦類的原文書。有時不完全懂書的內容,但是翻出來給讀者試讀,反而比懂內容的人翻得易讀。不是自誇自己功力高,或許是源於對文字的敏銳度,前後讀個幾次,把文順順,非弄到不拗口不罷休。

這過程當然是很辛苦的,但因為是有酬勞的,還是做得很起勁。
曾經有一本書的稿費讓我在當年(1988左右)能買一台TOYOTA的轎車。
但是這裡翻譯純粹是自願的。
所以,小弟對於版上翻譯志工的辛苦付出,在這獻上無限的敬意。
「漢書文書處理系統」作者,在這向大家學習。

MyBlog 梅僧山房

Utensil
Moderator
Moderator
Posts: 423
Joined: Sun Feb 03, 2008 11:38 am
Location: China

Re: 感謝翻譯志工辛苦的付出

Postby Utensil » Thu Aug 20, 2009 9:49 am

HeMason wrote:小弟受益於這個論壇,是想有機會時可以回饋一下,或許幫忙翻個幾段。
但是想到翻出來後,可能大家反而看不懂,所以我看算了,還是不要現醜得好,呵呵呵~


本来是一点小小商榷,可不要打击了前辈的积极性才好,呵呵~

前辈此愿,是论坛之福。前辈不要怕译法不同,一来,自动转换不难,二来,台湾IT著述、译作较多,我们对台湾译法也是时常遇到。(正如我们虽然写不出繁体字,却往往认得出来。)

前辈文字功底,小弟是非常相信的,也非常期待您的译作!

PS:最近前辈来到论坛,十分活跃,给论坛带来清新之风。小弟虽虚为版主,却因工作忙碌,许久未发言了,待有空时再给前辈的一些帖子回帖 :D

Regards

Utensil
In fascination of creating worlds by words, and in pursuit of words behind the world.

On Github: http://utensil.github.com
Technical Blog in Chinese: http://utensil.iteye.com/

HeMason
Experienced Solver
Experienced Solver
Posts: 73
Joined: Tue Jun 30, 2009 10:07 am
Location: Taiwan
Contact:

Postby HeMason » Thu Aug 20, 2009 10:05 am

在這裡被稱呼「前輩」會折壽啊!
小弟一個C寫了二十幾年,有夠不長進的了,這裡不能論年齡啦!還是要論「功力」。哈哈哈~

有點不好意思說,當年侯捷就坐我旁邊!(小弟在工研院混了七年半)
結果,卻沒好好把握機會向他學。真是慚愧到家了!
當時聽他在工研院講「 MFC」猶如天書,實在是自己被計畫框住了,沒適時學新東西,所以混到現在才來學,真是汗顏!
小弟跟同學、朋友講,我現在還在寫程式,他們驚訝到眼珠都要掉出來了!哈!

言歸正傳。
小弟對wxWidgets 只摸了三個月,覺得這是好東西。
因為要開發漢書新版(V10),有很強的驅策力。
日後常有叨擾,還望版上前輩不吝賜教。
這樣摸索起來就不感覺孤獨了!

再次感謝!
「漢書文書處理系統」作者,在這向大家學習。

MyBlog 梅僧山房

sxzhaoxiaoyue
In need of some credit
In need of some credit
Posts: 3
Joined: Thu Apr 19, 2018 5:21 am

Re: [翻译进行中]wxWidgets C++ Users Forum FAQ

Postby sxzhaoxiaoyue » Fri Apr 20, 2018 1:07 pm

看到前辈们的翻译和对话,在我的眼中看各位前辈,如幼儿仰望成人。高山仰止,景行行止,虽不能至,然心向往之。


Return to “wxWidgets Development (Chinese)”

Who is online

Users browsing this forum: No registered users and 3 guests