Commit Graph

11 Commits

Author SHA1 Message Date
gorhill 67417c5cec cleaning up old stuff 2015-04-10 02:17:12 -04:00
gorhill f2ff0edfaf this fixes #1013, #1062 (draft) 2015-03-27 13:00:55 -04:00
Chris 30eafed70a More µ to u 2015-03-09 22:00:48 -06:00
gorhill 7a5d09b4a2 this fixes #665 2015-02-04 18:06:31 -05:00
gorhill 084f092c33 re #550: use non-minified external libs 2015-01-30 08:04:52 -05:00
gorhill 0c152b2859 fixed flawed 1st-/3rd-party test 2015-01-08 10:37:19 -05:00
gorhill 1fe7045b92 too many changes for #433: branching so that I can commit and keep working on it 2014-12-28 10:07:43 -05:00
Raymond Hill 2e4c0a2bfe remove depending on vapi-appinfo.js 2014-12-01 14:25:33 -02:00
Deathamns 6d49ef0dac Avoid using Chrome's @@bidi_* type i18n messages
... for the sake of portability.

When including vapi-common.js in an HTML file, then the body element there
will have a "dir" attribute filled with the current locale's direction
(ltr or rtl).

The following languages are considered right-to-left: ar, he, fa, ps, ur.
Everything else is left-to-right.

After the "dir" attribute is set, we can decide in CSS which elements
should have different styling for rtl languages (e.g., body[dir=rtl] #id).
2014-11-09 17:40:40 +01:00
Deathamns 749b6f186d Use a dedicated file for storing extension info
Chrome has getManifest(), Safari doesn't have anything, Firefox has an
asynchronous API...
So, instead of using extension APIs, store the common informations
(extension name, version, homepage url) in a file (vapi-appinfo.js), which
can be included when it's needed (its data will be available at vAPI.app.____).
The file's content is updated each time the extension is being built, so
it shouldn't be modified manually.
2014-11-09 17:39:38 +01:00
Deathamns 5b79bf3536 Work on vendor API abstraction, and near complete Safari support 2014-11-09 17:39:12 +01:00