Fix eBay API initialization with site parameter

[ulandj]

Description

When initializing EbayAPI with the site parameter, the client fails to properly instantiate Site objects, resulting in errors:

EbayAPI.new(token: 'some', site: 'EBAY-US', sandbox: false)
# => #<EbayAPI:0x000000001188e8 @token=some, @site=Translation missing: en.evil.client.sites.EBAY-US, @charset=utf-8, @sandbox=false, @gzip=false>

There are 2 reasons:

1. I18n locale files not loading: The gem's locale files in config/locales/ are not automatically loaded when the gem is required by consuming applications, causing I18n translation lookups to fail.

2. Site initialization incompatibility: Evil::Client::Dictionary passes raw YAML data as a positional hash argument to EbayAPI::Site.new(hash), but Dry::Initializer expects keyword arguments. This results in all Site attributes being set to Dry::Initializer::UNDEFINED.

As a solution:

1. Added I18n locale path registration in lib/ebay_api.rb to ensure translations are available when the gem is loaded
2. Modified EbayAPI::Site class to detect when a hash is passed as a positional argument and convert it to keyword arguments. This maintains compatibility with both Evil::Client::Dictionary instantiation and manual EbayAPI::Site creation

[yevgenko]

thanks for fixing, overall looks good, proposed improvements to the tests

[nattfodd]

Should we merge [fix-ebay-api-initialization-with-site-param](https://github.com/main24/ebay_api/tree/fix-ebay-api-initialization-with-site-param) into master, and keep pushing PRs to master branch?

[ulandj]

for some reason there are many differences between master and support-catalog-product-search branch - #2. We can use our branch as a master, but it will require forth pushing to master :)

[main24]

LGTM overall, just worth removing redundant duplicate path part and omit bumping the version to avoid accumulating version conflicts.

[main24]

One of 'config' path parts can be removed:

Suggested change

	I18n.load_path += Dir[File.join(GEM_ROOT, 'config', *%w[config locales ** *.{yml,yaml}])]
	I18n.load_path += Dir[File.join(GEM_ROOT, 'config', *%w[locales ** *.{yml,yaml}])]

[main24]

Is it really necessary to support two ways of initialization? Wdyt about keeping only one, which would be easier to maintain?

[ulandj]

I want to avoid affecting other parts. As you mentioned, the fork is far behind the upstream version, and I prefer not to investigate or apply fixes if we plan to rebase onto the original gem.

[main24]

As the PR is opened not against the master branch there is no need to update the version.
The fork is well behind the upstream and could conflict with the upstream versions.

[main24]

LGTM overall, just need to make the test env reproduce the issue. Overlooked that in the first review, sorry. Please check the comment.

[main24]

To make the test actually checking whether everything is loaded correctly it's needed to remove I8n.load_path from the spec helper. Otherwise the test will be always green regardless of the fix.

ebay_api/spec/spec_helper.rb

Line 22 in d255b7d

I18n.load_path += ["config/locales/en.yml"]

[ulandj]

good spot! thanks