Translating into Russian
|
Posted
#64326
(In Topic #13872)
|
|
|---|---|
Fan in action |
|
|
|
|
Posted
|
|
ocStaff (admin) |
By default ocPortal is in ISO-8859-1 rather than utf-8. Unfortunately the web browser let's you type whatever you want even if it is not supported by the page's character set. It works on Comcode fields and some language strings because the browser converts them to HTML entities which Comcode can understand and some language strings are also HTML. There's a language string, charset, you can change. I'd recommend translating on Launchpad though, so you can get other people to help you. A few people have expressed interest in russian translation. If I answered something that you think should be in the documentation, please take the initiative and add it to the community documentation. We really need people to help out here and build a well-organised large support resource. |
|
|
|
|
Posted
|
|
|
Fan in action |
Wow, now you can see that string above I typed as HTML has been automatically converted for display into Russian word. Here it works. Mistery… |
|
|
|
|
Posted
|
|
|
ocStaff (admin) |
 .The Russian characters do not exist in iso-8859-1. Browsers let you type them but when the form submits it converts it to the HTML entities (with the & then the number) because there is no other way of storing them. You need to set ocPortal to utf-8 as described in the internationalisation tutorial. Sometimes ocPortal can display the HTML entities - but not in all spots, as you've seen. This is all normal behaviour, not a bug. I know it's confusing, but it's outside our control unfortunately. We can't turn utf-8 on for PHP by default as it's not officially supported by PHP and thus could have a few bugs. We also can't stop the browser allowing you to input characters that aren't in the character set because there is no browser feature for it. If I answered something that you think should be in the documentation, please take the initiative and add it to the community documentation. We really need people to help out here and build a well-organised large support resource. |
|
|
|
|
Posted
|
|
|
Fan in action |
$SITE_INFO['database_charset']='utf-8'; and $SITE_INFO['database_charset']='windows-1251'; providing cleared cashe from upgrade.php. That's the final outcome. |
|
|
|
|
Posted
|
|
|
ocStaff (admin) |
The database character set is different. If I answered something that you think should be in the documentation, please take the initiative and add it to the community documentation. We really need people to help out here and build a well-organised large support resource. |
|
|
|
|
Posted
|
|
|
Fan in action |
 . Good start. What has had a decisive effect is your advice concerning the 'charset' string changes to utf-8 and cache clearing. The database character set happened to stated in 'windows-1251' though. I am not sure whether it's right or not. Besides you mentioned earlier that utf-8 is not supported by PhP officially. How critical it is? You probably cannot say this. Thank you for help and beautiful script.
|
|
|
|
|
Posted
|
|
|
ocStaff (admin) |
I don't know of any problems with utf-8 (only one bug report ever, and was easily fixed), and I am very tempted to turn it on by default, but I think if I did probably occasionally new bugs would be found. If I answered something that you think should be in the documentation, please take the initiative and add it to the community documentation. We really need people to help out here and build a well-organised large support resource. |
|
|
|
|
Posted
|
|
|
Fan in action |
I'm on my way to reach complete translation, to gain perfection so to say. There are some weird things I've noticed so far. If you remember I've added following line
$SITE_INFO['database_charset']='windows-1251';
when I tried one day to clear site's cashes I've seen on my upgrader page completely warped text. Under the circumstances I've chucked off already translated file RU/upgrade.ini Now I see English version like this. Some of the places were left in Russian some uncleared though. 
The second think was that the left menu panels titles left untranslated as well as catalogues categories description, despite I'm sure I did translation of all these strings. 
I might've got into edit menu. And what I see there is 'main_content'. I shouldn't try to translate this. Should I? 
I'd be really appeciate any hint to resolve this issues Thanks. By the way my DB looks like this, threfore I am not able to enter any cyrrylic values 
|
|
|
|
|
Posted
|
|
|
ocStaff (admin) |
. The upgrader issue is a bug. We'll get that fixed for the next version. Menus get created from the language strings when you install, so if you translate the strings after then it would not affect them. It's the same with some other things too. So for your own site you'll need to use the menu editor to translate those. New installs would be fine. If I answered something that you think should be in the documentation, please take the initiative and add it to the community documentation. We really need people to help out here and build a well-organised large support resource. |
|
|
|
|
Posted
|
|
|
Fan in action |
1.I'd like also to report about few more irregularities concerning file permittion.ini first. It looks like this 
I did substitution for English version, little effect, first string appeared only as clear 'view access' in it. However it sees HTML title in Russian when you keep the cursor over it. 2. Transactions (manual). Is it possible to ad (edit somewhere) couple more currencies UAH and RUB? Besides in this countries any transaction is suppose to be joint with an agreement #, which could be a user's ID, but not the every user is a buyer. What we have in eCommerce are item name, item #, and amount. This agreement# might as well be an invoice #. I don't know it is not seen here in a drop down menu. Is it because I did not set a product list, yet? 
Also the currency is not shown. It's to be default one. Right? 
3. The custom profile fields. The options from drop down menu. They look strange. Is it because some of them are not editable? Anyway there has been programming error while I did editing 'About me', and some of the others not all options. 
And last one! I feel you are to upgrade my status to 'fun in action', ha,ha,  |
|
|
|
|
Posted
|
|
|
ocStaff (admin) |
0) I think you may just need to open up the sql dump as utf-8. Most text editors let you choose when you open the file. 1) See this note from the docs:
2) This is a bug/design flaw. It should provide more currency options and they should display correctly whatever character set is being used. I've attached a fix for 5.0.3. b) The manual transaction screen is not a main feature; basically if someone goes to purchase something but does not pay, you will see the option to say they have made a payment for it under manual transaction. If you want to get people to pay for something that isn't part of ocPortal then you can add an invoice for them. There is an option for that on the Admin Zone eCommerce page (Admin Zone > Usage > eCommerce > Invoices > Create Invoice). They will get a link to pay the invoice (e.g. by PayPal). You can also mark it manually as paid from manual transaction by selecting 'Custom work' and then the invoice will be in the list you showed. 3) Some of those names are hard-coded. ocPortal uses those names to read the CPFs for itself. We'll fix the 'VAL' bug you found there. CPF stats is just a minor feature though. If I answered something that you think should be in the documentation, please take the initiative and add it to the community documentation. We really need people to help out here and build a well-organised large support resource. |
|
|
|
|
Posted
|
|
|
Fan in action |
1.Sorry for not reading docs carefully. 2.Nice one. Thank you for fix. It works. 3.The current state of financial services in those countries is in development progress. Vast majority of customers do not have Pay Pal (which is brilliant I agree) accounts and tend to pay cash or use local shops to debit amount to certain company through the cash machine so as to get goods or services on prepaid amount. That's why they have to mention agreement # during payment procedure. Bearing in mind this conditions the manual transaction become a useful feature. You say I have as you see futher in anyway the only option is 'Custom work'. Link to pay the invoice. 
.It doesn't appear to be working I'm afraid. It leads actually to error page. 
I could've done a mistake somewhere. This catalog item going to the basket 
Thre are two items plus 17.5% VAT, ID#94237 
I'm creating invoice. See it as not paid yet. 
Than I receive an e-mail. And finally error as if it's nothing on the page. Moreover, when I cleared my basket. There were 2 items in the stock. (Min level 1 item.) And the system doesn't let me add a new same items. Not available it says. Despite i see quantites of two item when I press 'go to' to see details. |
|
|
|
|
Posted
|
|
|
Fan in action |
|
|
|
|
|
Posted
|
|
|
ocStaff (admin) |
If you'd like me to look at the unicode issue please send me a zip with the lang_custom/RU/*.* files and the SQL dump. I'm not sure about the last issue. I can't reproduce it when I try. The link is meant to disable cacheing whilst it loads, but it looks like cacheing saved for the left panel. Were you manually putting keep_cache=1 in your URL for some reason when testing? That could have confused it. Anyway, editing the panel with no changes should fix it. Thanks Chris If I answered something that you think should be in the documentation, please take the initiative and add it to the community documentation. We really need people to help out here and build a well-organised large support resource. |
|
|
|
|
Posted
|
|
Community saint |
 |
|
|
|
|
Posted
|
|
|
Fan in action |
|
|
|
|
|
Posted
|
|
|
Fan in action |
1.The currecy signs dissapered though, as you can see on the pictures. 
And here it says 'No price entry for the language'. 
2. The next issue I am afraid is regarding Setup Wizard. I've done it for second time. And what I discovered is following. I'am attaching two DB dumps, before and after, and language pack, so as it was easy for you to see. a. The Slogan underneath the logo actually stays the old one. Doesn't want to go b. The search box I've choosen it to be 50% wide. Besides I'd prefere it to be placed on the right hand side. No choice for this in dropdown menu. 
c. The home page became strangely presented in the two version layout  ? (See attach)
Conserning language pack. Currently it's pretty raw. I'm correcting one on every day basis. Because direct traslation does not always work. You have to find the appropriate word and reveal the essence of the IT term in a short way. Russian strings are always longer. I found your 'translate software' designer's tool very handy and useful. |
|
|
|
|
Posted
|
|
|
ocStaff (admin) |
I'm looking at the setup wizard issues now and language pack. If I answered something that you think should be in the documentation, please take the initiative and add it to the community documentation. We really need people to help out here and build a well-organised large support resource. |
|
|
|
|
Posted
|
|
|
ocStaff (admin) |
In the next version the setup wizard will add line breaks between rows of 50% boxes. But you can add them in yourself. Also we'll allow any side box to also be placed in the middle, but again you can do this yourself for now. Also I noticed the Admin Zone menu and zone menu had problems with font size so the next version will accomodate for this. I couldn't reproduce the site slogan issue, but we've changed the setup wizard a lot for the next version so maybe it's fixed. I had a very hard time understanding what was happening in the SQL but I worked it out eventually. The .sql file is in utf-8. However the database data in the file is written out byte-by-byte, each byte stored as a utf-8 character. So actually the .sql dump is double-utf-8 (meaning Russian characters will be 4 bytes in the end). I'm not sure what the fix would be. It's a weird thing. I do know you could edit the character set of your database and each table to utf-8, maybe that would make it write out character-by-character instead of byte-by-byte because it would know the output file and the database contents were both utf-8. But it might not, it really depends how the program doing the SQL reading/writing wants things to be. It's all a bit messy and confusing, but not really to do with ocPortal. If I answered something that you think should be in the documentation, please take the initiative and add it to the community documentation. We really need people to help out here and build a well-organised large support resource. |
|
|
|
1 guests and 0 members have just viewed this: None
Control functions: