Doesn't have much effect in practice, because charset and collation
are already hardcoded on an ALTER TABLE level (field definitions),
which take priority. Since most MySQL installs will still default
to a latin1 encoding, this propagates to the table though,
confusing devs and in some cases causing wrong data.
Example: A MSSQL->MySQL DB migration tool used the table metadata
to determine the charset, creating encoding issues.
In terms of hardcoding, we don't really support anything other than UTF8,
and the field-level settings are already hardcoded.
We should probably remove the field-specific settings and rely
on the DB defaults, but that's a sensitive API change
(need to set on existing DBs during upgrade).
It produces invalid HTML since the "for" attribute doesn't
map to any HTML input field. Each individual checkbox or radio button
input element has its own <label for>
- Based on new (last) translation download from getlocalization.com
- Removed untranslated strings. Getlocalization started including those at some point
which is highly annoying, unnecessary and breaks the new transfix system,
since it'll mark all of the english strings as actual translations
- Avoid dots in entities. It confuses the Transifex YML parser
- Removed some locales unknown to Transifex which didn't have any translations anyway
- Removed "lolcat" locale, uses custom notation (en@lolcal)
which SilverStripe's i18n system can't handle
(needs mapping from SS naming to Zend naming)
- Renamed "Te Reo/Maori" locale from "mi_NZ" to "mi" (Transifex/CLDR notation)
- Namespaced all entities used in templates (deprecated usage)
- Converted dots to underscores where template filenames are used for namespaces,
since Transifex YML parsing handles them as separate YML keys otherwise
- Removed whitespace in entity names, SilverStripe i18n can't handle it
- Only allow selection of locales registered through i18n::$all_locales to avoid
issues with unknown locales in Zend's CLDR database
Currently, the documentation implies that doing a `Children.max(LastEdited)` will work, which isn't the case.
This change uses `AllChildren.max(LastEdited)` instead, which while slightly more inefficient, will actually work consistently.
The recent flush filter fix had a problem that you couldnt set a custom
BASE_PATH in _ss_environment because that file didnt get included until
after checking the confirmation token. This patch pulls the part of Core.php
that defines BASE_PATH into a seperate file that can be included earlier
in the startup sequence so that ParameterConfirmationToken can access it.
Core.php includes Constants.php with a require_once call, so for startup
scripts that dont pull in Constants.php themselves (like cli-script.php)
no change is needed.
