BigCommerce's Optimized One-Page Checkout Mutilingual Limitations - bigcommerce

BigCommerce's Optimized One-Page Checkout allows some multi-lingual support. However, the language that is presented is decided based on the user's browser locale with no way for a user to manually override.
Why? And is there a workaround?

This is expected behavior of localization in the Optimized One Page Checkout. I personally have not implemented a workaround but others may have tried to and can share here, if so.

Related

Is there Yodlee FastLink configuration that is mobile-aware or responsive?

FastLink looks good stand-alone and in an 800x600 iFrame in the desktop browser, but I'm hoping there are some more mobile-friendly configurations that I just missed in the docs.
I see the access_type and displayMode parameters here, which would imply that what I'm hoping for is at least a possibility:
http://developer.yodlee.com/Aggregation_API/Aggregation_Services_Guide/FastLink_for_Aggregation/Yodlee_FastLink_Integration_Guide
I've been unable to find any other reference to those parameters in the docs, however, or more detail with regard to layout options.
Are there some other valid values for those parameters other than what's listed there in the Integration Guide, and/or some more detailed docs besides the integration guide and product guide?
FastLink looks like it has the potential to save significant unanticipated work on account setup, especially MFA -- I'm hoping we can get the FastLink UX to gel nicely enough with our own UX to not have to invest in rolling our own.
Currently there is no Fastlink available for Mobile/responsive one, although its in works and will be available in near future(no specific ETA right now).

How to Order management in ecommerce module for Orchard CMS

I'm developing an e-commerce module for Orchard CMS.
I cannot make decision for creating Order and OrderDetail as ContentPart or simple table.
What is best solution for implementing order section?
Please Help me and say your opinion and reasons.
As Bertrand points, I think that you only should make a ContentType entity that will take advantage from the Orchard's feature (or for faster admin development if isn't a heavy app). Be aware that the ContentItems are too abstract, so it has some penalisation (just use the debugger and you will see what happens).
Furthermore, are you aware that Orchard already has an ecommerce module? Try to follow DRY, and if you don't want to use it, at least, you should see the source code (Nwazet.ecommerce).
It really comes down to whether or not you want your Orders to be content items or not. As content items they can benefit from using features designed for use with Orchard. Some examples include indexing, built-in permissions, and dynamic type definitions.
There are sometimes reasons when you wouldn't want a model to be a content item. Maybe, for example, you might want to move your order system out of Orchard at some point. Not relying on Orchard's built-in features for order management might make that process easier.
Personally, I like to default to using content parts because I really like the Orchard architecture and I feel that it saves me a lot of time with boilerplate code. I only switch to using bare models after discovering a clear reason to do so.

Hiding a page part from Google, does it hurt SEO?

We all know that showing inexistent stuff to Google bots is not allowed and will hurt the search positioning but what about the other way around; showing stuff to visitors that are not displayed for Google bots?
I need to do this because I have photo pages each with the short title and the photo along with textarea containing the embed HTML code. googlebot is taking the embed code and putting it at the page description on its search results which is very ugly.
Please advise.
When you start playing with tricks like that, you need to consider several things.
... showing stuff to visitors that are not displayed for Google bots.
That approach is a bit tricky.
You can certainly check User-agents to see if a visitor is Googlebot, but Google can add any number of new spiders with different User-agents, which will index your images in the end. You will have to constantly monitor that.
Testing of each code release your website will have to check "images and Googlebot" scenario. That will extend testing phase and testing cost.
That can also affect future development - all changes will have to be done with "images and Googlebot" scenario in mind which can introduce additional constraints to your system.
Personally I would choose a bit different approach:
First of all review if you can use any methods recommended by Google. Google provides a few nice pages describing that problem e.g. Blocking Google or Block or remove pages using a robots.txt file.
If that is not enough, maybe restructuring of you HTML would help. Consider using JavaScript to build some customer facing interfaces.
And whatever you do, try to keep it as simple as possible, otherwise very complex solutions can turn around and bite you.
It is very difficult to give you very good advise without knowledge of your system, constraints and strategy. But I hope my answer will help you out to choose good architecture / solution for your system.
Boy, you want more.
Google does not because of a respect therefore judge you cheat, he needs a review, as long as your purpose to the user experience, the common cheating tactics, Google does not think you cheating.
just block these pages with robots.txt and you`ll be fine, it is not cheating - that's why they came with solution like that in the first place

How to prevent licensed video/document sharing?

If a website is to provide non-free content in terms of videos and documents, how is one about to serve this kind of content? I don't want to write an occasionally connected desktop application (similar to iTunes) that prevents to easily share bought content so I have a few questions about this:
Documents: What's best document format for this kind of scenario that would prevent one to share it freely after it was bought?
If I think of PDF it's a great format so people can't temper with its content and they will actually see what you created, but the problem is that after one obtains it, it can easily get shared with others. Either having password or not.
Videos: If supporting video it's probably wise to use some public (may be payable as well) service that can handle video streaming like YouTube (which is AFAIK not able to have a non-public videos).
I'm well aware that there is no 100% perfect solution that prevents it all, but having a 90% successfully locked down content is still better than hoping people won't share something that can easily be shared.
Can you list a few websites that do a similar thing. I may learn a lot from them. And please provide some guidelines I should follow in this regard.
Is there maybe a similar to PDF document format that has built in security capabilities? Commercial even... It should support some kind of authorization functionality within that would work similarly to any software activation.
Note: I wasn't sure whether this should be posted on webapps.stackexchange.com or here but I decided it should be posted here because it's related to development. I'm generally interested in programmable approaches I could use.

Solve Ubercart's Javascript Reliance?

Is their any way to solve Ubercart's Javascript Reliance?
Thanks
It would probably depend a lot on what Ubercart features you needed to use. The simpler your needs, the easier it should be to get away without having to require Javascript.
For instance, if you just used a single payment method, especially one like Google Checkout which bypasses the regular Ubercart checkout system, you might be able to get away without using Javascript with few if any modifications to Ubercart.