As discussed in acronyms in CamelCase, there are two opposing schools of camel casing – about whether acronyms should be uppercased or not – and there are also some styles inbetween that prescribe a bit of both. From that discussion, we may tentatively name them:
UnescoCase
XMLHTTPRequestCase
a bit of both:
length based rules:
MicrosoftIOCase (two letter rule)
Are there any existing names for this distinction? XMLHTTPRequestCase is a bit of a mouthful.
Related
Sorry this might be a very meta question,
What should I name a variable with internal capitalized word? for example, get FX rate,
getFXrate?
getFxRate?
getFXRate?
Or is there some material I can read upon?
Best Regards
One common approach is to use CamelCase only for abbreviations which are three characters ore more, for instance GetXmlSchema. In your example, however, where the abbreviation has only two characters, it would be the third alternative, GetFXRate.
There are three search strategies for own entities: trait, free-text and keywords, as explained in the documentation.
What I can't understand, is the allowed combinations of these options. I am able to choose either:
trait
keywords
free-text and keywords
Why can't free-text be chosen on it's own, only in combination with keywords?
Edit:
Definition of free-text, from the documentation:
When you need to extract a substring of the message, and this
substring does not belong to a predefined list of possible values.
Definition of keywords:
When the entity value belongs to a predefined list, and you just need
substring matching to look it up in the sentence.
From the definition, free-text and keywords look mutually exclusive to me. Therefore I can't understand why I can't choose free-text on its own, and why it is possible to choose both simultaneously.
I think solution in the word 'extract' in free-text and 'matching' in keywords, cause in case of free-text it extract substring from message but this substring has to have some words matches with original message.
in this example there is 'i will be' mutual with all messages, so we need both free-text to extract and keyword to match.
How do we convert Upper case text like this:
WITHIN THE FIELD OF LITERARY CRITICISM, "TEXT" ALSO REFERS TO THE
ORIGINAL INFORMATION CONTENT OF A PARTICULAR PIECE OF WRITING; THAT
IS, THE "TEXT" OF A WORK IS THAT PRIMAL SYMBOLIC ARRANGEMENT OF
LETTERS AS ORIGINALLY COMPOSED, APART FROM LATER ALTERATIONS,
DETERIORATION, COMMENTARY, TRANSLATIONS, PARATEXT, ETC. THEREFORE,
WHEN LITERARY CRITICISM IS CONCERNED WITH THE DETERMINATION OF A
"TEXT," IT IS CONCERNED WITH THE DISTINGUISHING OF THE ORIGINAL
INFORMATION CONTENT FROM WHATEVER HAS BEEN ADDED TO OR SUBTRACTED FROM
THAT CONTENT AS IT APPEARS IN A GIVEN TEXTUAL DOCUMENT (THAT IS, A
PHYSICAL REPRESENTATION OF TEXT).
Into usual sentence case like this:
Within the field of literary criticism, "text" also refers to the
original information content of a particular piece of writing; that
is, the "text" of a work is that primal symbolic arrangement of
letters as originally composed, apart from later alterations,
deterioration, commentary, translations, paratext, etc. Therefore,
when literary criticism is concerned with the determination of a
"text," it is concerned with the distinguishing of the original
information content from whatever has been added to or subtracted from
that content as it appears in a given textual document (that is, a
physical representation of text).
The base answer is just to use the LOWER() function.
It's easy enough to separate the sentences by CHARINDEX()ing for the period (and then using UPPER() on the first letter of each sentence...).
But even then, you'll end-up leaving proper names, acronyms, etc. in lower-case.
Distinguishing proper names, etc. from the rest is beyond anything that can be done in TSQL. I've seen people attempt it in code using the dictionary from MS Word, etc...but even then, Word doesn't always get it right either.
I found a simple solution was to use INITCAP()
I have to create sql function that converts special Characters, International Characters(French, Chinese...) to english.
Is there any special function in sql, can i get??
Thanks for your help.
If you are after English names for the characters, that is an achievable goal, as they all have published names as part of the Unicode standard.
See for example:
http://www.unicode.org/ucd/
http://www.unicode.org/Public/UNIDATA/
Your task then is to simply turn the list of unicode characters into a table with 100,000 or so rows. Unfortunately the names you get will be things like ARABIC LIGATURE LAM WITH MEEM MEDIAL FORM.
On the other hand, if you want to actually translate the meaning, you need to be looking at machine translation software. Both Microsoft and Google have well-known cloud translation offerings and there are several other well-thought of products too.
I think the short answer is you can't unless you narrow your requirements a lot. It seems you want to take a text sample, A, and convert it into romanized text B.
There are a few problems to tackle:
Languages are typically not romanized on a single character basis. The correct pronunciation of a character is often dependent on the characters and words around it, and can even have special rules for just one word (learning English can be tough because it is filled with these, having borrowed words from many languages without normalizing the spelling).
Even if you code rules for every language you want to support you still have homographs, words that are spelled using exactly the same characters, but that have different pronunciations (and thus romanization) depending on what was meant - for example "sow" meaning a pig, or "sow" (where the w is silent) meaning to plant seeds.
And then you get into the problem of what language you are romanizing: Characters and even words are not unique to one language, but the actual meaning and romanization can vary. The fact that many languages include loan words from those language they share characters with complicates any attempt to automatically determine which language you are trying to romanize.
Given all these difficulties, what it is you actually want to achieve (what problem are you solving)?
You mention French among the languages you want to "convert" into English - yet French (with its accented characters) is already written in the roman alphabet. Even everyday words used in English occasionally make use of accented characters, though these are rare enough that the meaning and pronunciation is understood even if they are omitted (ex. résumé).
Is your problem really that you can't store unicode/extended ASCII? There are numerous ways to correct or work around that.
We're working on revising the url structure for some of our movie content, but we aren't quite sure on the best way to handle odd characters. For example,
'303/302'
'8 1/2 Women'
'Dude, Where's My Car?'
'9-1/2 Weeks'
So far, we're thinking:
/movies/303-302
/movies/8-1-2-women
/movies/dude-wheres-my-car
/movies/9-1-2-weeks
Is this the best solution? Is there anything we're forgetting?
Use this format: /movies/123456/8-1-2-women
Set up your web server so that movies are identified by the numeric id (123456), and the rest of the path is ignored (only serves for SEO).
(Stackoverflow uses this approach)
We always use dashes.
I don't have a source off hand, but I have heard that the dash character is good for SEO purposes, better so than something like camel caps (i.e. dudeWheresMyCar) but not sure how it compares to underscores, ampersands, or percentage signs. Apparently with dashes (and maybe other separation characters too) search bots can "read" the links and add it as just one more factor on determining content relevance.
From Seomoz: "When creating URLs with multiple words in the format of a phrase, hyphens are best to separate the terms (e.g. /brands/dolce-and-gabbana/), followed (in order) by, underscores (_), pluses (+) and nothing."
This has been confirmed by Matt Cutts, Google too.