* Made the test suite for translations more complete
There were previously tests for translations within the test suite,
but they only covered a select few problem cases that had previously
been fixed. They did not cover the majority of cases, which makes
changes to how the translation mechanism for Select2 works a bit
more challenging.
So this adds tests for the majority of edge cases around translations,
including how one would expect the fallback chains to work and also
around how defaults interact with the language options. This should
not be considered an exhaustive list of all of the edge cases, but
it should be good enough to refactor the internals and not have to
worry as much.
The one change of note to this test file is that we are now properly
resetting the defaults in between tests. This should fix any issues
that we may have seen where the defaults were not being reset, and
thus tests were not properly isolated and would start to interfere
with each other. This required pulling the module definition down
below the imports, since we need to reference the defaults within
the module definition.
Many of these tests will fail because the translation system is
broken in many small, unrealized ways. The next few commits should
make these pass and fix the issues that we are seeing.
* Consistently resolve the language option
This fixes an issue that we have had for a while where we did not
have a way to consistently take the `language` option from a string,
array, object, or whatever else is specified and resolve it into
`Translation`-compatible objects or strings. Now there is a new
internal `_resolveLanguage` function which is able to take any of
the supported ways of specifying a language and resolve it down into
the supported language chain.
This now means that we can properly resolve the following cases,
and we can do it in a consistent manner.
* When the language is specified as just a string (for example: "en")
* When the language is specified as a string containing a region
(for example: "en-US")
* When the langugae chian is specified as a list of strings (for
example: ["es", "en"])
* When the language is specifid as an object containing messages
(for example, when a user overrides only a subset of messages)
* When the language is specified as a list of strings and objects
(for example, when a user wants to use a language other than
English and also wants to ovverride some default messages)
* When the language is not specified at all (the most common case)
* When the language is specified as an empty object (an edge case
that allows us to skip processing it)
This allows us to consistently produce the language fallback chain
based on the given `language` option, something which we could not
actually do before because we didn't have a consistent chain. This also
means that now the `language` option will consistently be an array
after going through this process, instead of being any number of
types before.
The translation generation currently does not support having objects
and strings mixed as a part of the fallback chain, despite that being
how the default chain has always worked, and as such there are still
failing tests around this.
* Move English to always be at the end of the language chain
This was technically true in most cases in the past, because if a
language chain was manually specified then it would have English
injected into the end of it anyway. This is needed because not all
translations are complete, but we know the English one is, and
Select2 relies on the translation that it uses being complete.
This will result in cases where a user specifies a language but still
receives English translation for some things, which is what users
have historically seen when using partial translations anyway. This
just ensures that there will always be a complete translation that
is being used, so they won't get unexpected errors and will instead
get unexpected English translations.
* Filter out repeated languages in fallback chain
This is mostly being done for performance reasons, since Select2
will not behave any differently when there are duplicates, but it
makes things cleaner when you ask for the fallback chain and it
only contains unique values.
This cannot distinguish between languages specified by name (string)
and languages specified by the contents of their language file
(such as the default, English), but this should generally not be
an issue.
* Convert the language chain into a finalized translation
This extracts the logic for converting parts of the language chain
into the finalized `Translation` objects out into its own method,
with some small fixes for edge cases.
This can now properly convert a language chain containing both
strings and objects into a translation object that contains them
both.
We no longer need to special case the `language` option being an
array since we know that it will be an array once the language
resolution process is completed.
* Switch default translation to be empty
This should have no external effects, but it fixes an interesting
bug where resetting the defaults would not always reset custom
translations. This was because it was possible to modify the
included English translation when you were setting a default for the
language option.
This should not cause any issues because the English translation is
now appended to the end of the language chain when the defaults
are applied, which means that English will continue to exist as the
final fallback.
* Inherited `lang` attribute should be below the default in the chain
It was pointed out in #5468 that the `lang` attribute, when inherited
from a parent element, was above the option set in the global default
within the inheritance chain. While this makes sense because of how
we inherit other properties, it does not make sense for the `lang`
attribute.
The inheritance chain for the `language` option has been adjusted
to be the following:
1. The `lang` attribute on the original `<select>` element
2. The `data-language` attribute on the original `<select>` element
(because of how `data-*` attribute resolution affects options)
3. The `language` option specified when initiailizing Select2
4. The `language` Select2 default
5. The `lang` attribute on a parent of the `<select>` element
While this is a breaking change, we believe that this change will
have minimal to no impact on real-world usage of Select2, because
of how the `lang` attribute is generally used within documents.
We believe this will now make setting the default language through
JavaScript easier and more reliable, bringing it in line with how
we recommend it is done within the documentation.
This was implemented through a new method `Defaults.applyFromElement`
instead of within the old `Options.fromElement` method because it
relies on the global defaults object. While we could have reached
in to the internals in order to apply it appropriately, it made
more sense to handle the proper resolution through a single
consistent place.
This was not implemented in the `Defaults.apply` method because that
method is not typically passed in a reference to the original
`<select>` element that it is applying the options for.
Closes#5468
* Properly resolve language chains with dictionaries
It is possible for a language chain to be specified that includes
both a dictionary and the string translation as a part of the same
chain, but we would previously throw an error because we assumed
that the list could only contain strings and that dictionaries
would never be included in lists.
This fixes the issue so language region normalization only occurs
when a string is specified in the language chain, which is what we
were previously assuming was the case but was not actually.
This also now resolves the entire language option during the
`Defaults.apply` method. This should be a no-op except for internal
tests, because the `Defaults.applyFromElement` method should almost
always be called in real-world scenarios.
This allows for more accurate resolution of the width when compared
to the `resolve` method. This is more relevant for jQuery 1.x, where
the `resolve` method cannot find the width of a hidden select box,
but it also applies to newer versions of jQuery where the `width()`
method provided by jQuery doesn't fully match `getComputedStyle()`.
Fixes#3278Fixes#5502Closes#5259
After we upgraded to QUnit 1.23.1, we gained support for
assert.expect(). This allows us to guard against any race conditions
within tests, because now expect() will be linked to the specific test
instead of the current running test.
The nested data attributes are only supported on jQuery 2.x or
browsers which support the `dataset` attributes on DOM elements.
In order to prevent test failures, and because tests cannot yet
be skipped conditionally, we just cut the test early.
This fixes the fallback path for the `data-ajax-url` attribute on
elements. As this attribute was previously supported in Select2,
the attribute has been migrated to the new, nested format of the
url and triggers a deprecation warning when it is used. Because
of a fix to the `data-*` attribute parsing made in a9f6d64 that
allowed for nested attributes to be parsed correctly in modern
browsers under jQuery 1.x, the deprecation warning would be
triggered but the attribute would no longer actually be used.
This also fixes some of the `.data` calls to use the camel cased
version of the key instead of the dashed version, which is the
preferred key and will be enforced in future versions of jQuery
as the only way to access data attributes.
Now in situations where the `dataset` attribute is used by Select2,
it combines the results of both `$e.data()` and `e.dataset` when
generating the object containing all of the options. This will
the `dataset` fix to still be used, while also still relying on
jQuery to do additional parsing on any options that it can.
The `dataset` fix is now only used on jQuery 1.x, as that is the
only version of jQuery affected by the dash issue. This is done
using version number parsing on the `$.fn.jquery` property that is
defined by jQuery. As this property is not defined in Zepto and
many other jQuery compatible checks, we only include the fallback
if the property is available. This assumes that any jQuery
compatible libraries that are in use will not include the same dash
issue, which we believe is a safe assumption given that it did not
match the HTML `dataset` specification.
This also adds a few tests to ensure that the deprecated attributes
still continue to function.
This closes https://github.com/select2/select2/issues/3086.
This groups tests into common HTML files so they can be run more
quickly. This also reduces the number of Sauce Labs instances that
have to be run, as one instance was previously spun up for each
file.
Now we are using `jQuery.noConflict()` in tests, so it should be
slightly easier to detect when this happens next time. Tests just
need to be written for the component.
This closes https://github.com/select2/select2/issues/2985.
This adds a check that triggers an error if Select2 was not able
to detect a copy of jQuery on the page. This should help users when
they are setting up Select2.
**Breaking change:** The full build no longer includes jQuery.
Previously, the full build included all requirements for Select2,
including jQuery, which meant that anyone looking for the optional
requirements had to possibly include multiple versions of jQuery
on their page. This means that anyone requiring Select2 to also
bundle jQuery will now need to include jQuery on their pages
alongside Select2. A copy of jQuery is included in the repository.
**Breaking change:** The AMD build of Select2 will now correctly
wrap the code in a `define` block. It will still create the named
blocks inside of the code, which should be valid in most AMD build
systems, so now Select2 is compatible with cases where the file
does not have the same name as the Select2 module name.
**Breaking change:** Select2 will re-use the AMD methods if they
are available on the page, but it will not longer leak the included
AMD loader to the global scope. The AMD methods will still be
available on the `jQuery.fn.select2.amd` namespace.
The `mock.js` test file has been renamed to `helpers.js` and will
handle the escalation of the `require` and `define` variables to
the global scope. It should be included in all test files, or the
tests will fail.
This closes https://github.com/select2/select2/issues/2946.
This also adds more documentation and corrects the release notes
for these breaking changes. These modules will now only be included
in the full builds of Select2, which has been noted in a few places.
This adds backwards compatibility with the `query` option so it
automatically patches the `DataAdapter.query` function. The only
major difference between the methods is the call signature, which
has now moved the callback out of the parameters and into the second
argument.
This also adds tests that verify that the old query functions should
work as expected.
Now if the old `initSelection` method is used, a warning will be
triggered in the console informing the user that it has now been
changed to `DataAdapter.current`, and they should create a custom
data adapter instead. We will still only call `initSelection` once,
and then default back to the old data adapter for calls after that.
This allows for mostly transparent support between versions.
This adds tests to ensure that `initSelection` operates the same as
it previously did, but now patches the `current` method of the
default data adapter.
In past versions of Select2, the `width` option could be used to
tell Select2 how to determine the width of the container generated
by Select2.
**Breaking change:** The default value for the `width` option has
been changed from `copy` to `resolve.`
**Breaking change:** The old option called `copy` has been renamed
to `style` to better reflect what the width is generated from.
This fixes https://github.com/select2/select2/pull/2090.
This fixes https://github.com/select2/select2/issues/2911.
This adds a test that makes sure that the inline data attribute
overrides the options that are passed in during initialization.
This also adds a test for the `createTag` option, which is used
when tagging.
