Download & Extend

Allow dynamic amazon locale choice

Project:Amazon Module
Version:7.x-1.x-dev
Component:Code
Category:feature request
Priority:normal
Assigned:Unassigned
Status:postponed
Issue tags:amazon-2.x

Issue Summary

As far as I understand, the module only supports using a single, statically chosen amazon locale. This is not ideal for global websites, where ideally the amazon website should be chosen depending on the current viewer's location and/or configuration.

Solving this is probably not an easy task, but as a first step, I implemented a change to the amazon_item_lookup function that allows the caller to specify the locale. I reused (and changed the name to 'locale") of the force_lookup argument, because anytime a specific locale is given, a lookup should be done (since the cache does not care about locales and would therefore return wrong data). I think the change is backward compatible, and that I handle the cache correctly (also not saving the result data in cache if the locale was specified). With this patch the cache can still be used in the same way as before, it is just ignored when using a specific locale. Reviews are obviously welcome to check this is correctly implemented.

Obviously more could be done to handle dynamic locales, but I hope this is a useful step in the right direction, which can already be useful for those using the API directly.

AttachmentSize
amazon.module.locale.patch2.46 KB

Comments

#1

Nice work! Thanks a lot. It helped to make my multilingual site work with different Amazon locale.

I've modified amazon_filter.module using your patch so that the filer can contain optional locale like [amazon full JP]. The only problem I still have is that Amazon associate ID can not be changed by locale. For example, I have different ID for amazon.com and amazon.co.jp.

<?php
function _amazon_filter_process_text($text) {
 
$pattern = "/\[amazon +(.*?)(?: +(.*?))?(?: +(.*?))?\]/";
 
$matches = array();
  if (
preg_match_all($pattern, $text, $matches)) {
   
$items = array();
   
$ids = array();

   
// Separate amazon items with and without locale
   
for($i = 0; $i < count($matches[1]) ; $i++)
    {
      if(empty(
$matches[3][$i]))
      {
       
// Locale is not specified. Add to the array of ids
       
array_push($ids, $matches[1][$i]);
      }
      else
      {
       
// Local is specified. Store id and locale pair
       
$loc_ids[$matches[1][$i]] = $matches[3][$i];
      }
    }
   
   
// Look up items for default locale
   
foreach(amazon_item_lookup($ids) as $item) {
     
$items[$item['asin']] = $item;
    }
   
   
// Then, look up items with locale
   
if(is_array($loc_ids))
    {
      foreach(
$loc_ids as $id => $loc)
      {
        foreach(
amazon_item_lookup(array($id), $loc) as $item)
        {
         
$items[$item['asin']] = $item;
        }
      }
    }

...
?>

#2

This is definitely great work, and I'm very interested in figuring out how that kind of flexibility can be leveraged through the whole module. I'm taking a closer look to see if there's any way it could be integrated with the efforts to make the affiliate id easier to change in realtime...

#3

It'll make Amazon module even greater if this can be integrated in some way!

#4

Yes, I would like to use multiple locals (US, UK, JP etc.) at the same time because my site is multilangual and targets multiple countries.

#5

When this feature will be implant into the Amazon module? It should be really great! :)

or maybe it's still impossible to have one affiliate id for each locale?

#6

Status:needs review» needs work

I'm definitely interested in a discussion of this patch. I think there are far-ranging consequences, though, and this patch definitely doesn't start to cover them. Remember that *every* API request to Amazon includes the locale, and in many cases the behavior is significantly altered. So for example, the available categories are different per locale, the search combinations are different, etc.

That said, adding a way to switch locale is *very* interesting and opens up a large area of possibilities.

#7

If we took this approach, we'd probably need to start storing the locale for each item in the DB along with the ASIN -- overlap/collision might be possible, for example, and we'd need to batch the API calls that run updates and 'refreshes' against the proper country's API endpoint....

#8

Version:» 6.x-1.x-dev

subscribing - a must have for international websites

#9

Community contributions are welcome.

Since Amazon does not have the same ASINs on each of its sites, the ASIN will have to be stored in our database correctly along with a locale element, and all of the queries will have to correctly reference that.

There would also have to be some configuration elements to say which sites are to be used.

A bit more needs to be thought out about this.

#10

Subscribe
A much needed feature. Thanks for all the great work and wonderful module

#11

Nice work!

getting information from amazon:
(my) nodes already have a language. A configuration which amazon shop to use for which language would be great.

I'm thinking about letting the user jump to the desired localeamazon shop of his choice dynamically.

The default valueshop can be based on:

  • an amazon choice field in the users profile
  • country of the users profile if no amazon choice field is present
  • the language of the node if not authenticated or the profile gives no hint

Just dreaming.
Gerd

#12

Unfortunately, the "locale" in Drupal/web/browser terms and the "locale" in Amazon terms are completely different things. To Amazon it just means which of several stores you're going to use. And those stores in many cases use different languages.

Patches and contributions are welcome. If we want this to happen, we'll have to talk design here.

#13

rfay:
thanks, I edited my comment to make this clearer.

#14

It's great to see that some work has been done on this already. I'm working on a site for English speakers in a region of Germany. Of course, since the primary users of the site are English speakers, it makes sense to have description info from the .com or .co.uk Amazon sites, perhaps even with some custom edits to indicate differences (e.g. electronics that differ from region to region in terms of the cables, warranty, etc). So far on my testing site, I've set my "locale" to Germany, but many people might visit the deployed site from other areas where there are Amazon stores local to them (U.S., U.K, France, Japan...) and it'd be nice to be able to refer them to English-language books about Germany (for example) which they could buy from their nearest Amazon store, before visiting or moving to Germany.

Anyway, I'm still getting the hang of how all this stuff works, but look forward to making meaningful contributions as I get my head around some of the trickier stuff. I've only recently dug into Drupal and have never had a site with Amazon referrals. I don't even know (yet) whether I'm required to have different Amazon associate referral IDs for the different stores I may be using, nor what to do to sign up for them in other areas of the world, so any tips for the new guy are most appreciated. ;-)

#15

@LoMo, your contributions will be welcome. I'll be happy to brainstorm with you about how this could be developed further. We could do a skype conversation or whatever. And you'll often find me on IRC.

Thanks,
-Randy

#16

Great, Randy. I'll work on learning a bit more about how all this works, first, so that I'm not feeling so n00bish when it comes to discussion of potential improvements to / implementations of this feature. My use case is a bit odd since I will mostly want to use English language descriptions (if possible), but non-English Amazon stores (mainly Amazon.de) for fulfillment of orders.

#17

I would really need to use alternate amazon local choice.
I don't think we need a so sophisticated feature, just add an optional local selection beside the amazon item that overrides the default configuration selection.

I am not a coder, but I will be happy to help for tests.

#18

I use amazon items from at least 3 amazon repositories (France / UK / USA)
Any hope this attribute would not be iron casted in admin settings?

#19

Contributions are welcome. Remember, this is just a community-supported resource. I personally don't have any sites using this, and no organization supports changes to it.

#20

..."no organization supports changes to it."
It seems that at least 10 people have expressed the needs for it.
I am not a coder, so I can only modestly contribute...

Many thanks for the great module.

(by the way, the amazon ASINs are identical for at least the 3 locales I mentioned. Some items are available everywhere, other aren't.)

#21

That's the point of the ASIN's, normally, to provide a consistent identifier for a product sold on more than one Amazon site. Unfortunately a lot of the products I've checked aren't available on multiple Amazon stores.

I'm still working to get the core of my site working, so I haven't done more than play with Amazon items yet, but I've been reading up (and viewing screencasts / other trainings, etc) on various kinds of Drupal development issues, including module dev, so hopefully, since I have a need for this feature (multi-locale support), I can help make this happen. Unfortunately, my use case is a bit unusual, so it might require some serious re-working of Amazon module core features... I'll have to see whether it would work to create what I do as an add-on module to the Amazon module or add them as various options, but first I've got a lot more to learn about all the code that's in it. In any case, it would be nice if what I do can be "contributed" rather than just my own personal "hack". ;-)

#22

@Lomo, I'll be happy to consult with you about the approach when you get there.

The key issue is that we cache the data in our database, so the locale will have to be part of the primary key for *each* item, since the data associated with the item is clearly different per locale. In many cases the ASIN seems to be different in different locales (certainly not available on all). So instead of just ASIN as the key, we'll have to use ASIN + locale.

#23

Subscribe
I´m also in need of this feature for a Spanish, English + German website.

#24

Subscribe

#25

Marked #456822: Use a different Amazon 'locale' with different subdomains, perhaps Domain Access as a duplicate. When we get to this we need to remember that the use case of doing domain access with different subdomains.

#26

Another thing that must be remembered: Associate IDs are per locale. So you'd have to enter a different associate ID for each locale.

#27

subscribe

#28

Version:6.x-1.x-dev» 7.x-1.x-dev
Status:needs work» postponed

Feature to be added in the 7.x.-2.x series. I'll take care as soon as we've switched to git and created the branch.

#29

I guess that's a "yes" about comaintaining Amazon! Yippee - I've added you on to the maintainers.

#30

tagging

#31

@ #29: Oops, I thought I had already said 'yes' in my last email! ;)
Still very nice of you that you're so happy about it! I'll try my best - my best efforts but no long-term promises atm.
Cheers, Pancho

#32

None of us can make unqualified long-term commitments to volunteer projects :-) Your current effort is much appreciated.

-Randy

#33

I'm actualy splitting my site into various subsites, which should have a shared database. Studying the apropiated modules I found out that 'Virtual sites' allows you to override variables, depending on the site.

Isnt it posible to change the Amazon locale that way?

#34

You'd also need to prefix amazon's and amazon_store's DB tables, but then such an approach should be certainly possible.

#35

On a multilingual website I have independent nodes for each language. In case I offer Amazon Germany and Amazon UK, I don't have any trouble about the product information. Because I have independet Nodes for each locale, which can get different ASINs.

Why would I need prefixed datatables?

In case one day I also go for Amazon US, couldn't I just define an independent language for the US section?

Is there any other module able to override the variables?
Virtual sites seem to be abandoned.

Im attracted to use 'Sites'. So it would be perfect to change the variables depending on 'Context'.
The other option would through 'Domain Access'.
I will post it there and let you know.

#36

The reason is that the item entries in the amazon DB tables are regularly updated by a cron job. As the API doesn't know which locale the item belongs to, so it will use the Amazon locale connected to the default language. So it will retrieve wrong data for some ASINs and no data at all for many others.

#37

In the Readme of "Domain Access" it sais:

4.5.1 Cron Handling

When Drupal's cron function runs, it runs on a specific domain. This forces
Domain Access to invoke its access control rules, which may not be desired.

In most use cases, you will want Domain Access to allow access to all nodes
during cron runs. For modules such as Subscriptions, this behavior is
required unless all your content is assigned to "all affiliates."

To reflect this, Domain Access provides a configuration option labelled:

[x] Treat cron.php as a special page request

This option is turned on by default. In almost all cases, you should leave
this option checked. Doing so allows Domain Access to ignore access checks
for nodes when cron runs.

That way it might be posible to run the cron independently on the nodes affilated to each site with different locale, without the need of prefixed tables.

#38

That might be an alternative you might want to further investigate.
On first sight, this might need a custom cron hook implementation.
However atm, we unfortunately have close to no time at all to help you with this request.
In a while, this will be solved in a general remake of Amazon module as 7.x-2.x

#39

Thank you for your suggestions.

#40

Is it possible that there is a backport for this work for D6? It's funny I would have thought that the same products in Amazon are available in all countries but they aren't. On second thought I guess that makes sense but it's frustrating for my client so having a solution like this would be awesome!

#41

I don't actually think there's any real original work, or work that applies. At this point it's a feature request.

#42

@rfay - thanks for the update man i appreciate that.