I've been looking into locale aware number formatting for javascript and found that Number.toLocaleString and by extension Intl.NumberFormat appear to be good solutions for this problem.
In particular I'd prefer building on top of already implemented abstractions for locale specific formatting rather than reinventing the wheel and coming up with one more solution to an already solved problem.
So I've called Number.toLocaleString on some different javascript environments and found that currency formatting seems to have changed:
(5).toLocaleString('fr-CH', {currency: 'CHF', style: 'currency'});
// Node v10.15.1: 'CHF 5.00'
// Node v12.1.0: '5.00 CHF'
// Firefox 66.0.2: '5.00 CHF'
// Chrome 73.0.…: '5.00 CHF'
// Safari 12.0.3: '5.00 CHF'
// IE 11: '5.00 fr.'
IE 11 is different than the rest, but it doesn't surprise me given its age.
What surprises me is that the formatting for CHF in fr-CH seems to have changed between node versions 10 and 12.
For comparison I had a look at the glibc LC_MONETARY settings for fr_CH and found that it seems to place the CHF before the amount at least about 1997. This makes it particularly confusing that the position of CHF seems to be different for most current browsers.
I would like to know and understand:
Why are the positions of the CHF different in these cases?
I know that this can depend on the available system locales or the browser. But the change between node versions seems to indicate a more recent and voluntary change to me.
Is there a correct way to place the CHF or are both choices acceptable for CH, or more specifically fr-CH?
For this it would be beautiful to have an actual source like a paper or research database rather than hearsay or anecdotes.
Update (2019-05-16):
In reaction to my partial answer I'd like to specify:
The formatting decision for fr_CH is given as currencyFormat{"#,##0.00 ¤ ;-#,##0.00 ¤"} in commit 3bfe134 but I'm still missing a source for the decision and would love to know about it.
So I've checked out the v8 source to see if I can find where the behavior of Number.toLocaleString is defined.
In builtins-number.cc I found the BUILTIN(NumberPrototypeToLocaleString){…} which uses Intl::NumberToLocaleString(…).
This led me to intl-objects.cc which implements the Intl::NumberToLocaleString using an icu::number::LocalizedNumberFormatter.
Since v8 uses icu I checked out the source to continue my search.
My first tries to find the source of the number formatting led me to look at decimfmt and numfmt first, but I somehow kept loosing the trace.
Then it dawned on me that it would likely make sense to keep the format definitions somewhat separate from the rest of the code. By looking around the website and the source more I finally found icu4c/source/data/locales/de_CH.txt and icu4c/source/data/locales/fr_CH.txt.
de_CH.txt has currencyFormat{"¤ #,##0.00;¤-#,##0.00"}.
fr_CH.txt has currencyFormat{"#,##0.00 ¤ ;-#,##0.00 ¤"}.
Now using git I found the commit that first introduced the currencyFormat for fr_CH (3bfe134) 19 months ago.
This is plausible to be between node v10 and v12.
I can also see that it it would make sense to fallback on de_CH before the curreencyFormat was added to fr_CH and therefore see that the format would change the way it did.
The commit mentions CLDR 32 alpha, and I found the CLDR charts version 32.
However I'm currently not able to figure out where the chart is located that defines the currencyFormat for fr_CH.
I feel that by finding the change to the fr_CH currencyFormat I found and understand the change that leads to the change of behavior between different node versions.
As of now I don't understand why glibc and icu have differences here, but that is something I can ask around in the context of the specific projects for.
I'm under the impression that I'm still missing the specific decision or data-point which led to the currencyFormat implementation - if I find it I shall add it here and be satisfied.
Update 2019-05-18:
The CLDR 32 data can be fond in the download section under cldr.unicode.org.
From there I could download the cldr-common-32.zip which included the file common/main/fr_CH.xml in which the currency format is defined like this:
<currencyFormats numberSystem="latn">
<currencyFormatLength>
<currencyFormat type="standard">
<pattern draft="contributed">#,##0.00 ¤ ;-#,##0.00 ¤</pattern>
</currencyFormat>
</currencyFormatLength>
</currencyFormats>
Via cldr.unicode.org I also found the survey-tool which is used to decide on these matters and to document the outcomes of such decisions.
In the Number Formatting section for fr_CH I could then see the decisions source:
Update 2019-05-21:
So out of curiosity I've asked about this on the libc-locales list as well as on the closest ticket I could find on the unicode-org ticket system.
This prompted me to investigate further and when researching this with a friend we stumbled upon the cldr repo on Github which is focused on CLDR data rather than having CLDR related data in it like icu has.
We found that commit c5e7787 introduced the first change that led to the CHF being placed after the number rather than before it and trough that commit became better aware of two tickets.
These tickets are CLDR-9370 and CLDR-10755, the second of which is a follow up that clears up some formatting.
While on the surface CLDR-9370 seems to mostly discuss the decimal separator, the currency symbol placement is discussed as well.
One of the sources given is a typography guide (pdf) published by the CERN which gives detailed instructions on the ways to write numbers.
For CHF the guide notes:
Using google translate this translates to:
Writing sums of money
The number is written in three-digit increments separated by a
non-breaking space (no point or apostrophe of separation), and is
followed (and never preceded) by the indication of the currency is
long or abbreviated. For name abbreviations currency, we use the ISO
code.
Related
The American Fuzzy Lop, and the conceptually related LLVM libfuzzer not only generate random fuzzy strings, but they also watch branch coverage of the code under test and use genetic algorithms to try to cover as many branches as possible. This increases the hit frequency of the more interesting code further downstream as otherwise most of the generated inputs will be stopped early in some deserialization or validation.
But those tools work at native code level, which is not useful for JavaScript applications as it would be trying to cover the interpreter, but not really the interpreted code.
So is there a way to fuzz JavaScript (preferably in browser, but tests running in node.js would help too) with coverage guidance?
I looked at the tools mentioned in this old question, but those that do javascript don't seem to mention anything about coverage profiling. And while radamsa mentions optionally pairing it with coverage analsysis, I haven't found any documentation on how to actually do it.
How can one fuzz-test java-script (in browser) application with coverage guidance?
Fuzzing a JavaScript engine draws a lot of attention as the number of browser users is about 4 Billion. Several works have been done to find bugs in JS engines, including popular large engines, e.g, v8, webkit, chakracore, gecko, or some small embedded engines, like jerryscript, QuickJS, jsish, mjs, mujs.
It is really difficult to find bugs using AFL as the mutation mechanisms provided by AFL is not practical for JS files, e.g, bitflip can hardly be a valid mutation. Since JS is a structured language, several works using ECMAScript grammar to mutate/generate JS files(seeds):
LangFuzz parses sample JS files and splits them into code fragments. It then recombines the fragments to produce test cases.
jsfunfuzz randomly generates syntactically valid JS statements from JS grammar manually written for fuzzing.
Dharma is a generation-based, context-free grammar fuzzer, generating files based on given grammar.
Superion extends AFL using tree-based mutation guided by JS grammar.
The above works can easily pass the syntax checks but fail at semantic checks. A lot of generated JS seeds are semantically invalid.
CodeAlchemist uses a semantics-aware approach to generate code segments based on a static type analysis.
There are two levels of bugs related to JS engines: simple parser/interpreter bugs and deep inside logic bugs. Recently, there is a trend that the number of simple bugs decreases while more and more deep bugs come out.
DIE uses aspect-preserving mutation to preserves the desirable properties of CVEs. It also using type analysis to generate semantic-valid bugs.
Some works focus on mutating intermediate representations.
Fuzzilli is a coverage-guided fuzzer based on mutation on the IR level. The mutations on IR can guarantee semantic validity and can be transferred to JS.
Fuzzing JS is an interesting and hot topic according to the top conference of security/SE in recent years. Hope this information is helpful.
I am working on front-end only React application and will soon be implementing internationalization. We only need one additional language... at this point. I would like to do it in a way that is maintainable, where adding a new language would be ideally as close as possible to merely providing a new config object with translations for various strings.
The issue I know we will have, is that we have dynamic inputs inside of sentences as demonstrated below (where [] are inputs and ** is dynamically changing data). This is just an example sentence... lots of other similar type things elsewhere in the app.
I am [23] years old. I was born in [ ______▾]. In 2055 I would be *65* years old.
We could break out 'I am', '*age input', 'years old. I was born in', '*year dropdown'. etc. But depending on the language, word order could be changed or an input could be at the beginning of a sentence etc, and I feel like doing it in that way would make for a really weird looking and hard to maintain language file.
I'm looking to know if there are common patterns and/or libraries we can use to help with this challenge.
A react specific library is react-intl by yahoo. Which is part of a larger project called FormatJS which has many libraries and solutions for internalization. These and their corresponding docs are a good starting point.
I am actually searching for a javascript / jquery library where I can pass a function equation, such as sin(x^2), and it plots the graph. Example link:
http://www.greatgraphing.me/?plot=sin(x^2)
Furthermore, I would like to scan my website for function equations and replace them with this function graph embed. It should have navigation features (scrolling, dragging the stage etc).
Over the last 4 hours I have searched the net without satisfactory result. Even the popular plot.ly, fooplot.com and jsxgraph do not offer this kind of features. The only thing that comes close to what I need is www.graph.tk. You can pass 1 equation by URL but it has no embed feature (widget or alike).
Wolframalpha offers a widget but it seems to be just an embed without the option to pass the equation.
Update: Found out that desmos.com offers an embed feature, if you purchase one of their API keys. Price is not stated.
I also considered using Google's geometry calculator but there seems to be no embed features.
Before starting to build such a "graph embed" myself, I would like to ask if such a project exists already. Maybe it is hidden in some github repo and I just can't find it.
Thank you.
PS: If the question is too offtopic (saw the first close flag), even though it is related to js/jquery, where should I ask it? On Superuser? Please advice me. I am sure this is an important question for many math developers.
All right, I took the time to write a first prototype based on jquery, math.js and easeljs (about 300 KB with v0.0.1):
graphobed
Demo: http://www.matheretter.de/tools/graphobed.html
Source: http://www.matheretter.de/tools/graphobed.html or here: https://raw.githubusercontent.com/echteinfachtv/graphobed/master/graphobed.js
Github repo: https://github.com/echteinfachtv/graphobed
Disclaimer: The code is a bit messy but worked in my tests. You just have to embed the js file, the script runs over all elements on your site and parses only if an enclosed equation has been found, the characters for enclosing are: *# x^2*sin(x) #*
I also added the possibility to change the graph later on by simply providing an input field. So after the embed you can change the graph as you wish:
Enjoy and improve the source code if you like :)
I am looking for a JavaScript libarary for coding in a textarea (with proper indentation).
I found Behave.js (http://jakiestfu.github.io/Behave.js/). However, that is lacking one basic feature: Indent a new line according to the last lines indent. It only does automatic indentation by recognizing braces and parentheses. Also, Codemirror and MarkItUp do not indent according to the last line, as far as I could see.
Do you know either an alternative library that does exactly that (and potentially more) or a way to add (or enable?) that functionality in Behave.js?
The reason why I need indentation like last line is that I want to be able to use a non standard programming language.
OK, I found the answer.
The Ace editor is the absolutely best code editor for JavaScript as far as I can see.
http://ace.c9.io/ it is developed by Cloud9 and some time ago the whole SkyWriter/Bespin team from Mozilla joined their efforts and have merged some of their features into Ace.
I would like get meaning of selected word using wikionary API.
Content retrieve data should be the same as is presented in "Word of the day", only the basic meaning without etympology, Synonyms etc..
for example
"postiche n
Any item of false hair worn on the head or face, such as a false beard or wig."
I tried use documentation but i can find similar example, can anybody help with this problem?
Although MediaWiki has an API (api.php), it might be easiest for your purposes to just use the action=raw parameter to index.php if you just want to retrieve the source code of one revision (not wrapped in XML, JSON, etc., as opposed to the API).
For example, this is the raw word of the day page for November 14:
http://en.wiktionary.org/w/index.php?title=Wiktionary:Word_of_the_day/November_14&action=raw
What's unfortunate is that the format of wiki pages focuses on presentation (for the human reader) rather than on semantics (for the machine), so you should not be surprised that there is no "get word definition" API command. Instead, your script will have to make sense of the numerous text formatting templates that Wiktionary editors have created and used, as well as complex presentational formatting syntax, including headings, unordered lists, and others. For example, here is the source code for the page "overflow":
http://en.wiktionary.org/w/index.php?title=overflow&action=raw
There is a "generate XML parse tree" option in the API, but it doesn't break much of the presentational formatting into XML. Just see for yourself:
http://en.wiktionary.org/w/api.php?action=query&titles=overflow&prop=revisions&rvprop=content&rvgeneratexml=&format=jsonfm
In case you are wondering whether there exists a parser for MediaWiki-format pages other than MediaWiki, no, there isn't. At least not anything written in JavaScript that's currently maintained (see list of alternative parsers, and check the web sites of the two listed ones). And even then, supporting most/all of the common templates will be a big challenge. Good luck.
OK, I admit defeat.
There are some files relating to Wiktionary in Pywikipediabot and I looking at the code, it does look like you should be able to get it to parse meaning/definition fields for you.
However the last half an hour has convinced me otherwise. The code is not well written and I wonder if it has ever worked.
So I defer to idealmachine's answer, but I thought I would post this to save anyone else from making the same mistakes. :)
As mentioned earlier, the content of the Wiktionary pages is in human-readable format, wikitext, so MediaWiki API doesn't allow to get word meaning because the data is not structured.
However, each page follows specific convention, so it's not that hard to extract the meanings from the wikitext. Also, there're some APIs, like Wordnik or Lingua Robot that parse Wiktionary content and provide it in JSON format.
MediaWiki does have an API but it's low-level and has no support for anything specific to each wiki. For instance it has no encyclopedia support for Wikipedia and no dictionary support for Wiktionary. You can retrieve the raw wikitext markup of a page or a section using the API but you will have to parse it yourself.
The first caveat is that each Wiktionary has evolved its own format but I assume you are only interested in the English Wiktionary. One cheap trick many tools use is to get the first line which begins with the '#' character. This will usually be the text of the definition of the first sense of the first homonym.
Another caveat is that every Wiktionary uses many wiki templates so if you are looking at the raw text you will see plenty of these. The only way to reliably expand these templates is by calling the API with action=parse.