a / textr Goto Github PK

textr should have recommendations about using locale variable to help textr’s plugins authors

See
http://github.com/iamstarkov/typographic-quotes
http://github.com/iamstarkov/typographic-quotes-l10n-db
http://github.com/andrepolischuk/typographic-numbers
/cc @andrepolischuk

subj

checklist:

• README.md
• package.json
• test.js

the case that plugins’ authors cannot imagine all possible usage cases, so its pretty dangerous to make these assumption. So the best trade off, is just to do nothing with input if passed locale is not defined, the same goes with locales not supported by plugin. What do you think?

Consumers expect Textr to be a typographic engine itself rather than a tool for creating custom ones. And this confusion is entirely our fault.

You can add info as in Yeoman instruction in section Few words for plugin creators:

The name property must be prefixed by generator-. The keywords property must contain "yeoman-generator" and the repo must have a description to be indexed by our generators page.
http://yeoman.io/authoring/

Hi,

I was just wondering what are your opinions or ideas on running textr in-browser through something like require.js.

Are there any caveats? Could it work?

I guess it depends a lot on which plugins are loaded. But I am wondering about your opinion on this in general.

Cheers

sdsfs

With 0.3.0 you can set textr(defaults) and tf.exec(text, options). That will be useful for recursive usage textr bundles. For example, you can set {locale: 'ru'} on the top level of your bundles (with defaults or with exec(t, opts)).

The other one change is that options in the plugins can be used as context-object to pass data between the plugins. That achieved by cloning defaults and options to new object each times when you execute your trasformation stack. But I don't know use-cases for it. I know only one, but IMHO, it's antipattern:

var tf = textr()
  // set locale dynamically
  .use(function (text, ctx) {
    ctx.locale = navigator.locale;
  })
  .use(quotes)
;

current tests are testing concrete plugins, which is redundant plugins are full tested by it’s own, thats why I suggest that textr need more generic way of testing workflow itself and not implementations in terms of concrete plugins

• vim plugin
• atom plugin
• sublime plugin
• cli

File structure:

• index.js
• test.js
• README.md
• package.json
• .travis.yml
• mocha as tests runner

README structure:

• title
• desc
• installation instruction
• usage section with spec from tests
• and license note

just as sketch proposal. What do you think?

• Type
• Nature