The files are uploaded to transifex.com now, which means we needed
to consolidate the file names (= locales). Since Transifex doesn't allow
arbitrary JavaScript structures, we're using an intermediary JSON
format which gets transformed into the JS used by the framework.
See b59f3858af for generator logic.
Fixes https://github.com/silverstripe/silverstripe-framework/issues/2499
- 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
Broken link to edit docs, perhaps should link to repo instead of directory to avoid having a branch in the URL. Also added blurb to clarify what branch doc edits should occur in.
The current guides have a few areas where they recommend an approach that is more complex than what most people take.
- Rebase straight onto upsteam/msaster
- Force push a rebased branch
I also fixed the conflict resolution help to be relevant to rebase commands, and kept the push instruction out of the rebase instruction.
I don't know what that release candidate branch stuff is, but:
* I've never seen any of the core team do it
* I think it's overkill for most patches
* I think it's being too prescriptive: if contributors want to do that, that's cool, but it doesn't affect the core team.
* It makes our contributing guidelines more complex than they need to be.
The guidelines for contributing code were scattered across a section of contributing.md and collaboration-on-git.md. I've updated this to have separate contributing/code.md page with all the content in a single cohesive page. We also have contributing/documentation.md, contributing/issues.md and contributing/translation.md.
The use of GitHub for documentation isn't ideal in a world full of wikis,
but we do it because it has other substantial advantages. However, we
shouldn't assume that every would-be author is comfortable using pull requests.
This change presents the edit-on-github interaction as the most straightforward
one, suggesting that advanced users may which to check out locally.
