MrPhil

"You're buying a Samsung Galaxy. Would you like to purchase an Orion telescope to go with that?"

I haven't counted them up, but you can take a look and see if it's more work than you want to do. Install (or just unzip) a standard English version (2.3.3.4) and look in catalog/includes/languages at all .php files in files and directories including the name "english". If you want to do administration in Bengali too, look in catalog/admin/includes/languages. If you're comfortable doing admin in English, you can leave it alone. I would suggest comparing these files to some other non-English, UTF-8-encoded language pack to see how to name files, how to translate, and how to set up encoding as UTF-8. "WinMerge" is a good tool for doing side-by-side file comparisons. I don't think there is anything in the .sql file you really need to change (you will be erasing all the default categories and products, anyway). There appear to be a number of icons, buttons, etc. containing English language, which you may want to edit to change the language. Finally, most add-ons (if you install them) have some language strings you'll need to edit, and maybe some icons or buttons with English text.
 
Editing .php files should be done with a text editor that understands UTF-8, and can be told not to write a Byte Order Mark (BOM) to the file. There are many fine editors available for free that should be able to handle this. You will need image-editing skills to update icons and buttons. GIMP is very good, and is free.
 
Once you have a complete Bengali translation, if done correctly, you could submit it to osCommerce as an add-on. Keep in mind that as osC is updated, you will be expected to provide updated versions of your language package.

So, are you required by law to list the price as "including VAT", but PayPal needs it separated out as a tax? You're going to run into these complications when you build in a tax and have to remove it to display separately on the invoice. If the above is true, I'm wondering if it wouldn't be better to modify osC to store the price without VAT and when displaying a page or the shopping cart contents, to show price+VAT? What do you do for cases where VAT is not to be charged (sales to the U.S., for example?)? Is it possible to not tell PayPal that it's a tax, and just treat it as part of the base price ("including VAT")? There's got to be a better way than getting our undies tied in a knot over how to cleanly pull VAT out of a price and then putting it back in, accurate to the penny.

Try searching on Purchase Without Account. I'm not sure that there's a PWA specifically for 2.3.3, but it's worth a try if you haven't looked on those keywords.
 
By the way, debate rages about whether it's worth the effort. For just about any kind of purchase, anyway, the customer has to provide as much information (name, address, contact phone, credit card info, etc.) for PWA as for a normal account. It's just a small additional amount of information (ID, password) to make an account. For customers who think they'll likely be back, an account is a good thing. For those afraid that their account opens them up to spamming, or doubt that they'll be back any time soon (and will forget that they have an account), they'll prefer PWA. Having some kind of "do not send marketing information emails or snail mail to me" clearly available, along with a clear privacy statement, can persuade reluctant customers to open an account. My suggestion is that after they've entered all the information needed for PWA, gently suggest that by adding a couple more bits of information they can have an account and save having to enter all that information again. Leave the ultimate decision up to the customer, or you could lose the whole sale.

Make sure you're starting with the right Russian language pack for your osC version (you should be at 2.3.3). There is a Russian pack for 2.3 and an upgrade from 2.3.1 to 2.3.2, so make sure you don't overlook any files or entries within files. Comparing that to the standard 2.3.3 English, you can see what needs translating, but first make sure you understand how to install the Russian add-on, so when you test your Georgian add-on, you'll know how it's supposed to install. Both Russian and Georgian should be UTF-8 encoding -- make sure you know how to edit a file in UTF-8 and save it without a Byte Order Mark (BOM).
 
You can translate either the Russian or the English into Georgian. If you want to, you can leave the admin side untranslated from English (copy in the English files if your starting point is the Russian package). If you start with English, make sure the georgian.php file sets the correct locale and encoding.

It is not necessary to inform visitors about cookies that are essential to the function of the site (such as maintaining the session connection). If you have not added anything else using cookies to osC, you are fine. On the other hand, if you add something like (?) Google Adwords, which uses a tracking cookie, that's what the law requires you to inform visitors about and ask permission to use. The law is intended to protect visitors from an invasion of privacy by the use of tracking cookies.
 
If you came late to the party and have no idea what add-ons (with cookies) are being used, something like cookieguard may be necessary.

It's telling you that line 1 of admin/includes/functions/general.php is outputting something, and it shouldn't be. Check for hack code added to the beginning of general.php, check for blanks before <?php, check for a Byte Order Mark (UTF-8 editing).

Thinking about it some more, I have to say that it's a complete waste of time to give a layman a WYSIWYG HTML editor. At least, for all the editors I've ever seen, a layman will screw it up badly. For example, the code has an ordered list (<ol>) with 4 items in it. The store owner wants to add a 5th item. What are they going to do? Add a paragraph with a hard coded 5. in it at the end! If they can see the tags (and have the training to understand them), or the editor has a tremendous amount of smarts to restrict what they can do ("Here is a numbered list between this mark and this one. You can add, remove, move, or change a list item.") it might work. To hand a WYSIWYG editor over to an inexperienced store owner will lead to lots of problems. They will complain to you that the new 5th element doesn't quite match the look of the rest of the list, so fix it!
 
That said, if you still want to explore the possibilities, I'm sure something could be done. One thing would be to offer an editor page in the admin, where you could keep a list of all the defines for each page, and use an editor such as CKEditor to update them. If you can get at least the common CSS in effect, that would be good. To write an edited entry back into the file would be challendging, as it could have multiple lines. Any apostrophes would have to be escaped. The referenced editor for 2.2 seems to be something along these lines.
 
Another method would be a Wiki-style edit button for each separate define. For just one specific user ID (the store administrator), the regualr catalog pages would be built with each define'd text in its own id'd <span>. The page designer would put an edit button (seen only by the administrator) for that text somewhere on the page, preferably close to the text (or a toolbar could be used). When mousing over the Edit button, the corresponding text would be highlighted so the administrator knows which text they'll be editing. Click on the Edit button to pop up a CKEditor page (using the existing CSS, or refresh this page to invoke the editor). When saving, again escape apostrophes and rewrite the language file. The advantage here is that all the page's normal CSS is in effect. A nice extra would be to restrict the editor width to the final width of the element, to keep the formatting as close as possible to what they'll actually see on the page.
 
So, it could be done, with various degrees of success for someone who knows HTML and can work with a WYSIWYG editor to edit an existing page. For your Average Joe, I don't think the results will be worth the effort, unless you can find a fantastically sophisticated WYSIWYG HTML editor that won't let them mess up the page (call this "Prussian model editing").

ROTFLMAO. Just wait until Amazon et al. big boys push through similar legislation in the US to get rid of all their pesky little competitors. Let's see... Microsoft hides some function in IE10 to hide cookie usage from the Feds for selected friends... all competing browsers are outlawed (as insecure)... the little guys' sites can't function very well without cookies and no one shops any more except at the big boys... are we sufficiently paranoid yet?

I had to chuckle when I read that. The "Wild West" never was. It was purely 20th century mythology built up in the movies and TV shows. According to historians, there was actually less gunplay in the dusty streets of almost any western settlement than there is today in most large US cities. Disease, privation, isolation, abuse of Indians and minorities, sure. Wild? No.
 
The Internet and the World Wide Web were architected on the premise that its users would be basically honest and fair in dealing with each other. In academic, military, and government usage, that was probably a fairly safe bet. Once it was thrown open to commercial usage, and money could be made, the cockroaches poured out of the woodwork. I'd almost say that you had it backwards -- it started out genteel and is getting rougher and rougher.

I'm not sure what text you're asking about. When I switch to English, everything is in English except for the logo HIUKAN... and your breadcrumb trail (navigation links) at the lower right. For the breadcrumb trail, I would assume that the code should be the same as the top right breadcrumb trail, which does switch between languages. What did you do there different from the top? I would put them into a common function so that they always come out the same.
 
A few suggestions on the breadcrumb (second navigation bar):
Never, never, EVER hard code a non-ASCII character in a general code file. I'm talking about the double right guillemet >>. Use » instead (notice that the real breadcrumb uses that). If you ever change page character encoding, you'll be in deep trouble with those characters not displaying properly. Non-ASCII characters are OK only in a language file, where a specific character encoding is expected.
Speaking of which, those links on the right aren't really a breadcrumb, so you should use something other than » to separate them. Using >> gives the impression that's a breadcrumb (a nested series of links) rather than separate top-level links. "|" (&vbar;) is commonly used for this purpose, as are various variants such as broken bars (¦) and double bars ||, and even bullets • and other symbols.
You have an extra >> at the end of the list. People will be puzzled and look around for the next item.
Consider putting this set of links on the same line as your real breadcrumb. It just looks odd being offset onto the next line. If you fear that the two of them together will be too wide to fit without wrapping around, I would suggest left-justifying the navigation links (under the real breadcrumb list).

How did you attempt to change the permissions? Many servers are now configured to silently ignore chmod requests from FTP clients. Try using your hosting service control panel > file manager. I don't quite follow your sequence of 'changing permissions to 444, save, upload'. If already 444 on the host, you need to change it back to 644 before uploading. Once the file has been updated on the host (after uploading), you change it to 444. You don't do anything to the file on your PC -- just to the one on the host (site).

Is that just for the base osC code, or does that also fix any arbitrary contribution's code? I suspect the former, which means the OP will still have to manually fix any deprecated code found in her added contributions.
 
http://us.php.net/manual/en/migration53.deprecated.php is the full list of PHP calls that may need to be changed, and how to change them.

It's certainly possible to develop a perfectly usable layout using tables -- indeed, until CSS matured, it was the only way to do it. However, keep in mind the drawbacks: it can be difficult to modify a table-driven layout if it's at all complex, it's slower to load, it can be positively hostile to the visually impaired (using screen readers), and it may not provide as good of search engine results as a div + CSS layout. I would certainly recommend using div + CSS for new work, but it's a judgment call as to whether it's worth converting over something old (and working), unless you're doing extensive changes anyway, or expect it to be around for at least 5 years.

Check the payment service agreement. I don't think PayPal allows you to charge an extra fee, and other services may or may not allow it.
 
If it's allowed, I don't think there's anything built-in to charge an extra fee based on the payment type. Have you looked through the contributions to see if there's something already written for it? One complication is that legally you will have to inform the customer of the extra fee (since you're already past the checkout page and totals when they select the payment type) and give them a chance to select another payment type or cancel the transaction. How about just adding a transaction fee for everyone, as part of shipping and handling?