* Add defaultHeaders flag that controls helpful default heders that can sometimes interfere with apis
* Bump version number
* rename parameter to useDefaultHeaders, and catch one location where the default was not being set properly.
* Use a better comparision operator
* remove bad change
* refactor: use files to add prefix
* fix: always use $tw.sjcl
* refactor: move sjcl to lib/sjcl
* fix: require sjcl in lib/
* refactor: move sjcl.js back into /boot
* Introduced preliminary idea for infinite recurse exception
* Better handling of infinite recursion
But it could be better still...
* the TransclusionError is a proper error
Moved the magic number to be on the error's class. Not sure if that's
a great idea.
* Fixed minor minor issue that came up in conflict
The minor fix to the jasmine regexp that escaped a '+' somehow
broke some random test.
* Initial Commit
* Fix plugin library URL
* Need to set plugin library location for prerelease
* Styling tweaks
* Docs
* Add tests that the core plugins all have a valid stability field
* Update chinese language files
* Add chinese translations for the new `<$testcase>` widget
* Update chinese language files
* Add chinese translations for the new <$testcase> widget
* Initial Commit
* Add note to preview build
* Fix whitespace and indenting
Thanks @pmario
* Fix crash with unset $tiddler attribute on <$data> widget
Thanks @CodaCodr
* Don't duplicate "description" field in test cases
* Use different background colours for nested testcase widgets
* Extend the testcase widget to run tests
* Add testcases to control panel
* Add a view template body template to render testcase tiddlers
* Test edition should display testcases
* Whitespace fixes
* Make testcase tiddler tempalte link to itself
* Styling tweaks
* Docs improvements
* Styling tweaks
* Run the new tw5.com testcases in the test edition
* Update data widget to display its content in JSON
* Add testcase convenience procedure
* Clearer testcases for data widget, and docs tweaks
* Don't expect our intentionally failing test to pass
* Extend testcase default template so that the display format can be chosen
It is selected by setting the variable "displayFormat"
* DataWidget docs typo
* Fix data widget not refreshing
* Links in testcase output switch to the tab containing that tiddler
Thanks to @btheado for the suggestion
* Docs update for 648855e8a5
* Wording tweak
* Add support for narrative tiddlers in test cases
* Documentation improvements
* Cleanup comments
* Remove obsolete code comments
* Simplify template
* Docs update
* Rename $:/core/ui/testcases/DefaultTemplate/SourceTabs from $:/core/ui/testcases/DefaultTemplate/Source
* Use the view template body for failing tests
* Don't reference the geospatial plugin
* "Test case" should be two words
* Fix handling of currentTiddler variable
Fixes problem reported by @btheado in https://github.com/Jermolene/TiddlyWiki5/pull/7817#issuecomment-2103704468
* Prepare for merging
* fix parsing error with spaces before reEndString, update docs to clarify block mode inside block quotes.
* additional advanced example
* oops, convert spaces back to tabs.
* reset indentation
* final tabs
* missed some
* wikitext classes are appended to other leading wikitext, no need to skip whitespace here.
* Make month and weekday names lowercase
* Replace AM and PM with Polish words
* Adhere to recommendations wrt short weekday names
https://sjp.pwn.pl/poradnia/haslo/dni-tygodnia-i-inne-roznosci;1788.html
* Fix a typo
* Inflect month names
I assume they're always used as part of the full date,
and in this case months are always inflected in Polish.
* Use roman numerals in place of short month names
I could not find any actual use of short month names in Polish.
The only mentions are from people trying to translate English
conventions into Polish - typically in software.
In https://sjp.pwn.pl/poradnia/haslo/dni-tygodnia-i-inne-roznosci;1788.html
Mr. Bańko answered (translation mine):
Abbreviations of month names are less common, numbers are used instead.
Such abbreviations can be created [...]. However, one must take into account
that the reader will not understand them.
I decided to go with a convention that's in actual use, rather than to
force an English convention which is alien to non-software dev Poles.
APIs especially use 2XX response codes outside of 200, 201, 204 for responding to responses. Treat all "Successful" response codes (i.e. anything between 200-299) as successes, and pass the responseText.
* first pass at fixing bug 7878, needs testing
* clarify default behaviour in comment
* fix property typo, tested and works as intended
* remove debugger
