Privacy Policy Cookie Policy Terms and Conditions Wikipedia talk:繁简处理/档案4 - Wikipedia

Wikipedia talk:繁简处理/档案4

维基百科,自由的百科全书

目录

[编辑] 新的想法

由于wp是基于UTF-8的,在中文版中也可能有其他语言的文字出现(比如跨语言链接,繁简体可以在同一个页面中共存),我们现在的讨论繁简体问题也就必须基于UTF-8,而不能采用一般的转换为GB或BIG5的方式,否则有些文字可能会造成错误。也就是说,我们需要在UTF-8中进行繁简体的转换。不知道这在技术上是否可行?

另外,标题和界面也需要解决繁简体的问题。只有这样,才能彻底解决问题。还有就是链接文字的繁简体问题。所有这些都需要在UTF-8中进行繁简体的转换。

fiancee visa k1 visa fiance visa h1 visa green dot prepaid card green card dv 2007

根据上面大家的建议,我这样认为:(这种方法需要3个数据库,繁简混合数据库,简体数据库,繁体数据库)

由于解决繁简体问题是为了阅读上的习惯,因此可不可以这样,假设当一个人第一次来到这里,系统根据他的IP地址或浏览器的语言代码从简体数据库或繁体数据库中自动调用相应的文章,并把它记录到cookies中(当然界面也需要进行UTF-8的繁简转换)。这样当然有可能会出现一些判断错误,我们可以在网页的某个显著位置做一个到另外一个语言版本的链接。当登录为用户后,可以通过参数设置进行选择。当用户进行编辑时,在编辑框中则显示为原始的输入信息,也就是从繁简混合数据库中调入文章。保存时,将文章原样存入繁简混合数据库,并同时进行UTF-8繁简转换,产生繁简两个版本,分别存入简体数据库和繁体数据库,显示时则根据用户设定再从这两个数据库中选择一个调入文章。

这种方法可能比较复杂,而且可能需要对软件进行修改,但是可以根本解决当前所存在的问题以及以前讨论中提出的问题。这种方法对参与者可能有较高的要求,因为在编辑时需要看懂繁简体。

请大家继续讨论!--Shizhao 07:43 2003年12月8日 (UTC)

对了,使用这种方法前,必须对当前的文章进行一次清理,删除同名文章。比如亚细安亞細安只能有一个存在,否则会造成冲突。--Shizhao 07:47 2003年12月8日 (UTC)

這樣的化,那我們要越早決定越好;要不然到時候我們有7、8千文章的時候,怎麼整理啊?!應為這個一定要人工整理的,有些簡/繁體版有不同內容。-Menchi 07:53 2003年12月8日 (UTC)
上面Virtu有提到可以在数据库中保存繁、简两个版本,理由是编辑后只要转换一次就可以,而如果储存一个混和版本,则必须在每次显示时都进行转换,比较浪费时间。我觉得这个建议似乎更好,因为编辑次数总要比浏览次数少,而且转换时连标题一起转换,也解决了条目用简体还是繁体的问题。--Formulax 08:58 2003年12月8日 (UTC)
我和Virtu的意思差不多,只是多增加了一个繁简混合数据库,用来保存原始的输入信息,也是出于安全上的考虑。这个数据库只在编辑是才调用,阅读时只调用简体或繁体数据库。但是这个数据库是否可以不要呢?请大家讨论。--Shizhao 09:21 2003年12月8日 (UTC)
现在技术上没有任何不可行的地方。只是我们不懂PHP或者没有多余的时间。我也觉得数据库保留繁、简两个版本的好,这样每次编辑完成后只作繁、简两个版本的两次规范化就可以了。不管输入的是繁体还是简体的条目,每次保存编辑内容时,把编辑内容规范化为简体一个版本、繁体一个版本,分别保存起来。如简体用户编辑简体内容的亚细安后保存,系统自动生成亚细安亞細安的两个内容一致的新版本。这种作法唯一的麻烦是繁简标题相同的情况,如地名表,这种情况下用自动消歧义的方法来解决,自动生成地名表 (繁)和地名表 (简)这样两个条目。--Mountain 13:32 2003年12月8日 (UTC)
Shizhao说的“第三个数据库”可以不要。在我上面的这个方案里,WikiMedia原来的数据库表不需要变动。只是每次编辑分别各为数据库表cur和old产生繁简两个记录而已。--Mountain 13:32 2003年12月8日 (UTC)
Mountain是说不变数据库,只是产生繁简两个版本?这就带来了另外一个问题,就是条目计数会变成单一版本条目X2的情况。造成虚假的条目计数。而且自动消歧义会造成一个问题。比如在文章中链接地名表,就会显示为一个空的连接,因为只有地名表 (繁)和地名表 (简)才是正确链接。当然也可以用程序进行自动转换,但是这就更会加大服务器的负荷,而且很难保证不会出错。因此采用一个繁体数据库,一个简体数据库比较理想。但是这就需要对软件作比较大的改动。

另外如果采用两个数据库的方案,在方案实施前,必须进行清理,并且清理时一般用户不能编辑,只保留一个版本,比如把页面先全部手工转化为简体,删除相同的繁体版本。工作量很大(几千个页面)。而使用三个数据库的办法,就不需要进行清理,只是在编辑时可能会繁简体共存。

或者还有一个办法,在实施方案时,新建两个数据库,一个简体,一个繁体,现在这个数据库作为临时数据库。繁简两个数据库建好后,在一个页面没有编辑前,用户浏览页面调用临时数据库,第一次编辑文章后,将文章分别转换为繁简两个版本保存到各自的数据库中,而将临时数据库中的相应页面删除,以后浏览编辑这个页面就采用两个数据库的方法。直到临时数据库中的所有文章全部被删除,临时数据库就可以取消掉,采用两个数据库的方法。这种方法比较简便,就是需要对系统做一些修改,但是不会出现以上讨论出现的情况。

综上所述,现在问题集中在数据库的处理上,有以下几种方法:

  • 2个数据库
  • 3个数据库
  • 3变2数据库

请大家发表看法--Shizhao 14:50 2003年12月8日 (UTC)

:還有一個方法,把繁體版簡化後的內容放在簡体版的內容前面,存入簡体數據庫內;再把新的簡体版繁化放在繁體數據庫內。那就只要2个数据库,而且全部可自動操作,不經人手。結果是同一版本裡內容可能重覆兩次,但用户浏览時,就很容易改正了!Wshun 05:39 2003年12月9日 (UTC)

或者只用一个数据库,在数据库中增加一个字段,现在的文章仍然存放到原来的字段,新的字段存放繁体版内容。然后根据用户设置分别读取简体或繁体内容。这样不需要增加数据库,只需要对数据库做一些修改就行了。只是数据库的大小会比原来增加一倍。这样是不是会更简单一些?--Shizhao 05:49 2003年12月9日 (UTC)
會不會繁簡體內容不同? Wshun 05:53 2003年12月9日 (UTC)
我的意思是,根据用户习惯读取相应的繁简体页面,编辑保存时,分别转换保存为两个版本到各自的字段中去,整体上仍然是一条记录,但是却有两个版本(不会造成条目计数错误)。而且内容肯定是一致的。--Shizhao 06:00 2003年12月9日 (UTC)

IP地址或浏览器的语言如果不容易處理,或不準確的話,那就給第一次来的讀者第一個頁寫:

請問讀者想使用簡體繁體版?

Menchi 07:53 2003年12月8日 (UTC)

我想不用吧。我局的可以在页面上方“打印页面”的旁边增加一个链接,如果系统判断显示为繁体页面,则这个连接上的文字为“简体版”,点击后可以转换为简体。反之亦然。而且这样任何时候当用户想看另一个语言的版本都马上可以看到,虽然这种情况可能会很少出现(我是空有想法,却不会编程,唉...)--Shizhao 08:15 2003年12月8日 (UTC)

[编辑] 跨语言链接的问题

想到一个问题,在其他语言版本的到中文的跨语言链接如何解决?如果使用多个数据库,到中文的链接是用简体还是繁体?想到一些方法:

  1. 2个数据库:根据跨语言链接上的中文,系统自动判断使用哪个数据库。或者根据中文版上用户的语言设置,系统判断使用繁体还是简体。
  2. 3个数据库:采用#1的做法,或者调用繁简体混合数据库。
  3. 采用现在其他语言版本的做法,分别建立与繁体和简体的链接,(即使用zh-cn,zh-tw)。这种方法比较简单,而且在中文版中也可以解决繁简体之间的切换问题。但是这种方法最好是系统自动完成。即在其他语言上做跨语言链接时,使用[[zh:中国]],保存时系统自动生成[[zh-cn:中国]]和[[zh-tw:中國]]分别连接简体数据库和繁体数据库。在中文版上系统可以自动生成到另一个数据库的链接,比如一个简体用户编辑中国条目后,系统自动生成[[zh-tw:中國]]。这样是否比较好?

还有没想到的吗?--Shizhao 03:13 2003年12月9日 (UTC)

还想到一个问题,就是界面的问题。现在的界面全部是简体,我们如何进行繁简体的转换呢?如果采用一般方法,每次调入页面时,界面都将作一次繁简体的判断和转化工作,会加大服务器的负荷。

我的办法:将语言文件作这两个,分别对应简体和繁体,系统根据设置自动调入。另外,现在使用mediawiki消息进行大部分的本地化工作,我们是否可以也采用2个数据库的办法进行处理?--Shizhao 04:02 2003年12月9日 (UTC)

这个办法我觉得最好,上次我问Brion他说可以办到。目前我认为可以先实现界面繁简体并存。我们现有的简体LanguageZh.php只要转换一下就可以安装,然后让Brion在中文版的用户设置中加入繁体、简体的选项选择界面就可以了。另外Mav在这里说对匿名用户不必根据IP地址自动给出不同的界面,只要再放一个链接在不同界面之间切换就可。这样就更方便了。--Formulax 07:01 2003年12月9日 (UTC)
和我的想法大体上一样,可以先把Formulax说的先做起来----

[编辑] Wiktionary的中文版问题

Wiktionary也将要推出中文版,我们是否也讨论一下这个的繁简体问题。由于它是一个字典/词典,因此繁简体问题比Wikipedia更加复杂。比如一个“国”字条目,他肯定要提到繁体的“國”,因此无法使用我们在Wikipedia上讨论的解决办法。因为所有的文字都将会转化为简体。而且如果“國”字作为条目,必然涉及到它的简体形式,这个矛盾如何解决?难道设两个条目?一个繁体的“國”,一个简体的“国”?但是这两个条目释义肯定都是一样的,因为都是一个字。我想到一个办法:使用一个特殊的标记,被标记的字词不做繁简体的转化,其他内容的处理则采用Wikipedia上的办法。


[编辑] "張三豐"還是"張三丰"

簡體版是“张三丰”,繁體版應是"張三丰",但有人用“張三豐”。怎樣可以防止繁簡轉換時出問題?這帶出二個問題:若必要同時使用繁簡體,怎麼辦?Wshun

你可以参看我前面讨论的内容。我们可以使用一个标记符号,被标记的文字不进行繁简体处理,这样是不是可以?但是标题就无法这样处理了--Shizhao 06:04 2003年12月9日 (UTC)
漏看了那一段,是好方法--Wshun 06:14 2003年12月9日 (UTC)
或者我们对标题进行处理,设置一个选项,允许标题不进行繁简体转换。或者编辑时设置两个标题,分别对应繁简两个格式,由于这样可能会造成混乱,这个功能是否可以只允许管理员使用。--Shizhao 06:51 2003年12月9日 (UTC)
我的意見是:所有標題不要進行轉換,這樣可允許更大的彈性,如“张三豐”。Wshun 07:08 2003年12月9日 (UTC)
可是不转换看起来不奇怪吗?比如标题是简体,内容却是繁体。而且内部链接也很难处理,必须知道标题是简体还是繁体才行--Shizhao 07:31 2003年12月9日 (UTC)
是怪了一點,但可以接受。內部鏈接卻是個問題,想不通 :p Wshun 23:52 2003年12月9日 (UTC)

回應見Re:"張三豐"還是"張三丰"

[编辑] 跨语言链接

现时是否可以暂时采用跨语言链接的方式对繁简体页面进行链接,而不使用现在的繁简体链接做法?就是说使用zh-tw和zh-cn,向其他语言的跨语言链接一样,出现在页面的上部,而不像现在一样放在文章里。这样做比较方便,而且也比较好看,不会影响文章的版面布局。参看w:New York, New York。现在中文版上无法实现,不知道是什么原因?--Shizhao 02:03 2003年12月17日 (UTC)

[编辑] 用UTF

上网时间太长,头比较晕,这里的讨论也没看完,但是,要下网了,先说两句。(上网时间长是因为从这里引出的网站太多了)。用繁简分离的方法,让中文人群被阻隔,不好。最好用UTF方式。然后,如果建立时用的条目名称是简体,那么相应的繁体条目重定向到简体,反之亦然。用繁简同步转换的方法技术难度比较高,也容易出问题。最好不要提高技术难度,用简单办法解决比较好。

新增:可以将简体和繁体都作为阅读的选项,在编辑时只能编辑简体和繁体混合的UTF-8编码格式。这样就避免了阅读困难,也解决了简体和繁体共存的问题。

Tomz 16:24 2004年1月20日 (UTC)


[编辑] Solve the problem in one shoot

Chinese should be a single language, not two or more. Wikipedia should only have one Chinese version. For the economic of maintenance and for usage, one version is better then two or more versions. 中文應該是一種語言文字, 而不是兩種或以上. 所以 Wikipedia 應該只有一個中文版本. 無論從維護的經濟性或從讀者的使用方便來說, 單一版本都是較佳的.

The current usage of Chinese is unhealthy, mainly due to a wrong policy of P.R.C. However, Wikipedia is a international project, we should not limited ourselves to this error. 中文發展到目前的狀況, 可以說處於一種不正常的狀況, 這部份是中華人民共和國政府的語言文字政策造成的. 因為Wikipedia是一個國際性的項目(project), 我們不必要將自己局限在這種錯誤之中.

We have to admit that personal names, cooperated names, trade marks, proper names is not suitable for conversion, they should be presented as they are. If this held, then every page in Wikipedia should have traditional and simplified characters co-exist. Any pure simplified or traditional schemes shall fail at some point. 首先, 我們要承認繁簡體是應該並存的, 人名, 機構名稱, 商標, 專有名詞等不能進行繁簡體轉換. 所以從任何角度來看, 所有頁面都應允許繁簡體並存的. 故此任何純簡體或純繁體的方案都是最終會失敗的.

The usage of language changes due to time-space various. Thus, the terms used shall be considered when design Wikipedia. 其次, 中文的使用地域廣泛, 各地區之間的用語皆有不同. 且會隨時間不斷變化. 因此, 在設計Wikipedia 的時候有必要將此因素考慮進去.

Here is the proposal: 我提出的方案是:

Maintain a single version of both traditional and simplified Chinese version 只維護單一允許繁簡體並存的中文版

We need to maintain a glossary (table of representations of the WikiLinks). The glossary is used to provide links to the same page of different form of WikiLinks, and automatically convert to the representation accroding to the locale a user selected. 除了構築作為百科全書的Wikipedia外, 建立不同時空的術語表(Glossary). 所有鏈結(Wikipedia中的詞條)都需要在術語表之中, 即是說, 建立可以由機器自動替換的術語表. 而可替換的都應由人手標示.

For example, 如:

[计算机]/zh-CN = [電腦]/zh-TW = [Computer]/en.

All of them links to the same definition. 它們都對應同一頁面.

When the user request either one of them, the page is automatically converted to simplified character if required, and all links inside that page is converted according to the locale. There shall not be convert from simplified to traditional characters as human intervention is preferred for accuracy. The conversion can be done in machine assistance however. 當用戶要求[计算机] 或 [電腦] 時, 將頁面中的文字和其中的術語 (Wikipedia Link) 自動轉換成用戶設定的語境 (zh-TW, zh-HK, zh-CN, zh-SG, …). 轉換將包括繁體向簡體的轉換和將Wikipedia鏈結轉換為術語表中相應的語境的形式. 自動轉換最好不要由簡體向繁體轉換, 由簡體向繁體的轉換應該由機器輔助下由人完成.

This require a new feature of WikiMedia, however, this also provide a possible to link all versions of Wikipedia. For example, linking up [Computer] to a Chinese pages. 這需要Wikipedia 中加入新的功能, 但這亦給予Wikipedia不同語言之間融合的一種途徑: 只需對術語表進行擴充即可.

In operation 實際運作時, 會有以下的情境:

1. 頁面創建時創建者可以選擇自己所善長的. 2. 如果頁面中有簡體字的, 為方便繁體字用家, 可以進行人工的簡體到繁體的轉換, 這道工序等同對頁面的編修. 但請不要修改當中的鏈結. 3. 對包括繁體的頁面編修時, 僅懂簡體的用戶需要尊重繁體字的用家, 最好盡量保留其中的繁體字(因為繁體字比簡體字要準確一些, 可以自動轉換成簡體字, 而簡體字則不能). 我建議可以開兩個Window一個顯示簡體, 一個編修, 這樣可以同時學習一下繁體字. 4. 維護術語表. 這是一項新的工作, 但其成果亦相當有用.

1. Page creator can choose whatever character they known best. 2. If a page contain simplified characters, for benefits of traditional users, someone can edit the page and convert the simplified characters to traditional correspondings. The edit should not convert the links. 3. When edit a page contain traditional characters, a simplified user may not known all the characters or can input them. He can still do the edit in any character set they can use. However, I would like them to leave the existing traditional characters untouch. The can open two windows, one display the page in simplified characters the other use for edit. 4. Maintain the Glossary. This is a new task. However the result can be very useful.


楼上提到的张三丰,呵呵。这样的字一共有53个(在整个简体和繁体相互转化的过程中,例如“原、叁、坎”等)。偶可能算个这方面的专家了吧?

可惜现在没什么时间能贡献的,不好意思。

总的意见,只保持一个数据库是肯定的,不可能弄两个简体数据库出来。 至于两岸语言习惯的不同,例如“平治”--“奔驰”,“信息”--“资讯”,“通过”--“透过”等等,你最好认为它们是同义词或者其中一个是方言。这样的情况就算在内地也是很常见的:

“卫生间”--“洗手间”--“盥洗间”--“男界”--“女界”--“厕所”--“茅房”......

除非你打算彻底解决同义词的问题,否则在这种类似于方言的东东上花工夫没有意义。 ——只需要进行简繁转化就好了,语言习惯我看就别管了,反正大家都明白其含义就好。

--218.88.210.2


语言习惯的解决办法


关于同义词,我建议使用超级链接,让发现与本地语言中说法不同的时候可以加一个超链接,或编辑已添加的链接,如对上面提到的所有的同义词都可以加这样一条超链接“普通话厕所,也叫“卫生间”,香港叫“盥洗间,湖南俗语叫“男界”和“女界”……”(关于地域的说法无实据,但是我想如果是由各地的朋友加上去的,我们就可以确信了)。这样不但可以收集同义词,促进中国地区文化的繁荣,因为各地都可以用自己的说法进行编辑,又不妨碍其它地方人的理解。我认为这样做同时能够成为一种地域文化的载体。

[编辑] 不同地域语言习惯的解决办法

语言习惯的解决办法


关于同义词,我建议使用超级链接,让发现与本地语言中说法不同的时候可以加一个超链接,或编辑已添加的链接,如对上面提到的所有的同义词都可以加这样一条超链接“普通话厕所,也叫“卫生间”,香港叫“盥洗间,湖南俗语叫“男界”和“女界”……”(关于地域的说法无实据,但是我想如果是由各地的朋友加上去的,我们就可以确信了)。这样不但可以收集同义词,促进中国地区文化的繁荣,因为各地都可以用自己的说法进行编辑,又不妨碍其它地方人的理解。我认为这样做同时能够成为一种地域文化的载体。

[编辑] 繁体与简体转换问题

中文条目中,牵涉政治分歧的条目,在繁体简体互换的过程中,应该注意以下问题: 1、删除有政治分歧的内容; 2、对于特定概念或涵义,解释加注中华民国中华人民共和国或者大陆地区台湾地区,我想彼此可以接受。

Cncs 2004-03-04

这个是麻烦的问题,请大家讨论讨论。Ktsquare (对话、留言按这里) 02:00 2004年3月3日 (UTC)
我觉得不必,完全可以在文章中说清楚,把各方的观点都列出来,这就是中性的观点--Shizhao (Talk) 05:50 2004年3月3日 (UTC)
我們要不要現在就開一個條目,做一個收集各個中文字的繁體和簡體對應情況表格?中文繁简体对照表 Dowba 11:28 2004年3月5日 (UTC)
可以呀--Shizhao (Talk) 11:40 2004年3月5日 (UTC)
我發現似乎不用那麼麻煩了,有一個相當好的 PHP class 可以做到在 UTF8 編碼下轉換,這裡有介紹Dowba 14:11 2004年3月6日 (UTC)
對了,如果在程式(你們稱之為編程)方面有需要協助的話我可以幫忙! Dowba 14:11 2004年3月6日 (UTC)
Of course we need ur help! :) this issue has been bothering us for too long a time! any solutions? --Samuel 14:15 2004年3月6日 (UTC)
看到这个程序了。但是看他的说明文档,似乎不能用在这里。现在维基百科使用的就是UTF-8编码,我们只能考虑在UTF-8下进行繁简体转换,而不能通过GB或BIG5的转换实现,因为有可能会让一些其他语言的文字在转换过程中丢失--Shizhao (Talk) 14:29 2004年3月6日 (UTC)
這個就可以轉換呀,我上面說過了。我把我轉換的程式碼貼在這裡吧。(假設 $str是一個UTF8編碼的簡體字串)

include "class.Chinese.php";
$chs = new Chinese("UTF8","GB2312",$str);
$str = $chs->ConvertIT();
$chs = new Chinese("GB2312","BIG5",$str);
$str = $chs->ConvertIT();
$chs = new Chinese("BIG5","UTF8",$str);
$str = $chs->ConvertIT();
echo $str;

也就是說,先把UTF8編碼轉換成GB2312,然後再轉成BIG5,最後轉換成UTF8。如果說你們需要轉換上面的幫助的話,非常樂意!能不能把程式給我研究一下?
问题就在这里,先把UTF8編碼轉換成GB2312,然後再轉成BIG5,最後轉換成UTF8,这个过程中,会造成一些语言的字符丢失,除非是UTF8简体直接与UTF8繁体互相转换,不通过中间过程。不知道我的理解对不对。主要是不能影响到其他语言的显示。或者可以在上面所说的转换过程中,只转换汉字,其他语言的字符可以不转换--Shizhao (Talk) 15:19 2004年3月6日 (UTC)

可否这样,只在UTF8内部转换:

include "class.Chinese.php";
$chs = new Chinese("zh-cn","zh-tw",$str);
$str = $chs->ConvertIT();
echo $str;

另外,维基百科的软件可以去http://wikipedia.sourceforge.net/ 下载--Shizhao (Talk) 15:24 2004年3月6日 (UTC)

關於有些字會丟失的問題,大部分都還是罕見字,因此問題不大,但說起來的確還有討論的空間……但是這應該不是最重要的問題,因為和漏字的問題比較起來,趕緊實現繁簡並存是最重要的。在程式方面,也許哪位可以 email 給作者請教這個問題:「如果來源碼翻譯之後,目標編碼沒有相對應的字元,能不能這個字就直接忽略,保存原來的UTF8編碼,而不是變成空白?」。這個問題其實應該是很好改進的,只要一點小地方更改即可。不過我不便使用 email ,所以說可能要麻煩各位? Dowba 15:30 2004年3月6日 (UTC)
只在 UTF8 內轉換是做不到的,因為轉換表格只有以下這幾種(以下摘自 Hessian 的 PHP 程式 "中文編碼集合類庫"):

       'codetable_dir'         => "./config/",           //  存放各種語言互換表的目錄 
       'SourceLang'            => ,                    //  字元的原編碼 
       'TargetLang'            => ,                    //  轉換後的編碼 
       'GBtoBIG5_table'        => 'gb-big5.table',       //  簡體中文轉換為繁體中文的對照表 
       'BIG5toGB_table'        => 'big5-gb.table',       //  繁體中文轉換為簡體中文的對照表 
       'GBtoPinYin_table'      => 'gb-pinyin.table',     //  簡體中文轉換為拼音的對照表 
       'GBtoUnicode_table'     => 'gb-unicode.table',    //  簡體中文轉換為UNICODE的對照表 
       'BIG5toUnicode_table'   => 'big5-unicode.table'   //  繁體中文轉換為UNICODE的對照表 

上表顯示的結果,簡體中文和繁體中文間所存在的直接編碼對應關係就只有GB2312和BIG5了,如果說要在 UTF8 底下實現,就必須以 UTF8 編碼作為橋樑不可。 Dowba 15:38 2004年3月6日 (UTC)

其实關於有些字會丟失的問題,主要是考虑到跨语言链接的问题--Shizhao (Talk) 15:49 2004年3月6日 (UTC)

在跨语言链接方面是怎麼樣的問題,我不大清楚? Dowba 03:03 2004年3月7日 (UTC)

對了,如果要解決漏字的問題,我們恐怕就得使用土法煉鋼的方法:把每個簡體(或繁體)中文字所相對應的字列出來,做成一個檔案,然後當使用者 submit 資料的時候逐字翻譯。可是這個工程很耗大呀。 Dowba 04:24 2004年3月7日 (UTC)

我現在進行翻譯試驗,但是一看到程式內部就覺得有點頭昏,因為它使用了相當多的 Class ,恐怕我不大能勝任。能不能請哪位和 WikiPedia 官方比較熟的,請教他們這個樣子:


Our Chinese Wikipedia site now want to adjust the program to save two version's of article, which includes Traditional Chinese and Simplified Chinese, at the same time after submitting.We got stuck when we edit the EditPage.php because of it's complication,the large amount of using PHP class. We can ofter the class using for translate Chinese.And can you help us? Thank you.


上面是我寫的英文,如果真的有人要幫我問的話就麻煩幫我檢查一下文法有沒有錯吧。

Dowba 06:22 2004年3月7日 (UTC)

每一個中文頁面都有兩種字型即可. 只不過每次改的時候都要改兩種字型.


我嘗試在wordpress內用ConvertIT(), 由utf-8顯示的繁體轉作簡體, 以下是修改的code:

$str = the_content(__('(more...)'));
$chs = new Chinese("UTF8","BIG5",$str);
$str = $chs->ConvertIT();
$chs = new Chinese("BIG5","GB2312",$str);
$str = $chs->ConvertIT();
$chs = new Chinese("GB2312","UTF8",$str);
$str = $chs->ConvertIT();
echo $str;

$str = the_content(__('(more...)'));
$chs = new Chinese("BIG5","GB2312",$str);
$str = $chs->ConvertIT();
$chs = new Chinese("GB2312","UTF8",$str);
$str = $chs->ConvertIT();
echo $str;

以上的code並不能把繁轉簡,

但我用了以下的code測試:

$str = "你好嗎編";
$chs = new Chinese("BIG5","GB2312",$str);
$str = $chs->ConvertIT();
$chs = new Chinese("GB2312","UTF8",$str);
$str = $chs->ConvertIT();
echo $str;

以上的code便能把繁轉簡

convertIT似乎不能把the_content(__('(more...)')) 轉換, 是什麼原因呢?

請幫忙!

breakfast


[编辑] Re:"張三豐"還是"張三丰"

From : Jason (jason@01box.com)

本人有以下提議 以php + mysql 做出自己的對照表

用統一的資料表, 格式如下:

CREATE TABLE `tbl_convert` (
`cid` bigint(20) NOT NULL default '0',
`direction` enum('both','t2s','s2t') NOT NULL default 'both',
`charT` varchar(10) NOT NULL default ,
`charS` varchar(10) NOT NULL default ,
`sortorder` int(6) NOT NULL default '0',
PRIMARY KEY (`cid`)
) ENGINE=MyISAM
** 也可在 charT, charS 上加上index

先找出一份全中文字表, 讀成Array $charaters // 以下假設找到UTF-8的繁體中文字表 include ("class.Chinese.php"); <?php

set_time_limit(0);
foreach($charaters as $k => $v){
$tmp = iconv("UTF-8","BIG5",$v); // $tmp = big5 繁體
$chs = new Chinese("BIG5","GB2312",$str);
$tmp = $chs->ConvertIT(); // $tmp = gb2312 簡體
$tmp = iconv("GB2312","UTF-8",$tmp); // $tmp = utf-8 簡體
$sql = "INSERT INTO `tbl_convert` ( `direction` , `charT` , `charS` , `sortorder` ) VALUES ( 'both', '$v', '$tmp', '500');";
mysql_query($sql);
}

?>


如之前的討論, 當中總有一些錯漏, 但由於所有資料儲下來了,可慢慢改正;

對於 張三丰 / 張三豐的問題, 可加入
INSERT INTO `tbl_convert` ( `direction` , `charT` , `charS` , `sortorder` ) VALUES ( 's2t', '張三丰', '張三豐', '400');

** 補充說明 使用時是以 ORDER BY  `sortorder` DESC 排列的
** 簡->繁 $sql = "SELECT * FROM `tbl_convert` WHERE direction IN('both','s2t') ORDER BY `sortorder` DESC"; or
** 繁->簡 $sql = "SELECT * FROM `tbl_convert` WHERE direction IN('both','ts2') ORDER BY `sortorder` DESC";

還可以再改善地方方言, 如廣東話
INSERT INTO `tbl_convert` ( `direction` , `charT` , `charS` , `sortorder` ) VALUES ( 'both', '耍太極', '打太極', '600');


eg echo s2t(張三丰打太極);
運行結果如下:
1st) 張三丰耍太極 //// sortorder 600 的優先, 500以上是人手輸入的詞語
2nd) 張三豐耍太極 //// sortorder 500 所有一段字元
3rd) 張三丰耍太極 //// sortorder 400 的修正, 500以下是修正用 詞語


結果 : 張三丰耍太極


如有錯漏不足的地方, 還望指正

上述方案由於未有全國字庫而未能動工, 如果 閣位得悉 有關字庫網址的話請留言 成品將發佈GNU 或 像fpdf般可供commerical use 的freeware

Jason
jason@01box.com

THIS WEB:

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - be - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - closed_zh_tw - co - cr - cs - csb - cu - cv - cy - da - de - diq - dv - dz - ee - el - eml - en - eo - es - et - eu - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gd - gl - glk - gn - got - gu - gv - ha - haw - he - hi - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mg - mh - mi - mk - ml - mn - mo - mr - ms - mt - mus - my - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - rm - rmy - rn - ro - roa_rup - roa_tara - ru - ru_sib - rw - sa - sc - scn - sco - sd - se - searchcom - sg - sh - si - simple - sk - sl - sm - sn - so - sq - sr - ss - st - su - sv - sw - ta - te - test - tet - tg - th - ti - tk - tl - tlh - tn - to - tokipona - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu

Static Wikipedia 2008 (no images)

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -

Static Wikipedia 2007:

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - be - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - closed_zh_tw - co - cr - cs - csb - cu - cv - cy - da - de - diq - dv - dz - ee - el - eml - en - eo - es - et - eu - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gd - gl - glk - gn - got - gu - gv - ha - haw - he - hi - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mg - mh - mi - mk - ml - mn - mo - mr - ms - mt - mus - my - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - rm - rmy - rn - ro - roa_rup - roa_tara - ru - ru_sib - rw - sa - sc - scn - sco - sd - se - searchcom - sg - sh - si - simple - sk - sl - sm - sn - so - sq - sr - ss - st - su - sv - sw - ta - te - test - tet - tg - th - ti - tk - tl - tlh - tn - to - tokipona - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu

Static Wikipedia 2006:

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - be - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - closed_zh_tw - co - cr - cs - csb - cu - cv - cy - da - de - diq - dv - dz - ee - el - eml - en - eo - es - et - eu - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gd - gl - glk - gn - got - gu - gv - ha - haw - he - hi - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mg - mh - mi - mk - ml - mn - mo - mr - ms - mt - mus - my - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - rm - rmy - rn - ro - roa_rup - roa_tara - ru - ru_sib - rw - sa - sc - scn - sco - sd - se - searchcom - sg - sh - si - simple - sk - sl - sm - sn - so - sq - sr - ss - st - su - sv - sw - ta - te - test - tet - tg - th - ti - tk - tl - tlh - tn - to - tokipona - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu