| Re: Proposal for a "universal language" system. |
| by irmtfan on 2013/1/12 5:59:42 Quote:
I just thought it would be good standard to separate translations from functions (I should save the file contain translation in utf-8 without BOM but i can save the file contain functions in any standard format) but we can wrote translations and methods in fa.php as you proposed. Quote:
yes. you are right. I think it is possible with your proposal.(if we dont follow any standard and let users to do what they want) Just i dont know what will happen on performance when we extend such a number of classes? here: 1- en extends XoopsLocalAbstract 2- pt_BR extends en (translation + functions) 3- pt_PT extends pt_BR (translation + functions) 4- XoopsLocale extends pt_PT about multilingual XOOPS: Our only problem with the old system is the limited space in the field and we have this issue only in "title fields" not "text fields" eg: i never run out of space in a news body/post body. i always have issues with news titles/ forum names/ categories,... So I think nodes for text fields will not solve anything regarding multilingual unless you want to implement nodes for "any content" which i think is bad for performance and developing. |
| Re: Proposal for a "universal language" system. |
| by trabis on 2013/1/11 13:29:30 Quote:
Ah, I got it but... let me go back a little. My first propose was 2 files per language: 1 - One file just for type casting (ex: XoopsLocale or ModuleLocale) 2 - One file to hold translations and methods (Ex: XoopsLocaleEn or ModuleLocaleEn) Then I though you proposed 3 files per language 1 - One file for type casting 2 - One file for translations 3 - One file for methods What you did propose however was using 2 files: 1 - One file for type casting and methods 2 - One file for translations The only problem I see with your propose is that a pt_PT/XoopsLocale cannot extend a pt_BR/XoopsLocale and it would have to implement the methods with copy/paste. In my propose this could be done since the translation classes can extend other translation classes(they have different names). Personally I think your propose is good/better. I think that all languages should extend just the english version. Full translations should be provided for pt_PT and for pt_BR and same goes for methods. You agree? |
| Re: Proposal for a "universal language" system. |
| by Mamba on 2013/1/11 11:13:37 Quote: I know how this method works but i think it is a useless extra work for multilingual purposes. It needs changing all current modules database structure and having more queries at the end while we already dont have problem with current modules. I am not for one particular method of achieving it. If there is a better way, let's do it that way. The goal for us is to make XOOPS the "Best and easiest to use Multi-lingual CMS". The globalization is more and more happening, and more and more people and companies want to have a multi-lingual Websites that are easy to create, use, and maintain. Quote: So while im not against of using these kind of nodes i think you should consider easy developing and good performance too. Absolutely! That goes without saying! 
|
| Re: Proposal for a "universal language" system. |
| by irmtfan on 2013/1/11 10:19:29 Quote:
We didnt have Pt XoopsLocalAbstract in xoops 2.5.5 and we dont need it. we already have Xooplocale class in locale.php so for local parties we just write our local functions. eg: or for persian numbers i can add local number format. I cannot see any problem. local functions in locale.php and translations in fa.php |
| Re: Proposal for a "universal language" system. |
| by trabis on 2013/1/11 7:52:48 Quote: irmtfan wrote: then this in local language: |
Search
Recent Posts
Who's Online
Donat-O-Meter
| Stats | |
| Goal: | $15.00 |
| Due Date: | Jul 31 |
| Gross Amount: | $0.00 |
| Net Balance: | $0.00 |
| Left to go: | $15.00 |
|
|