If you read a lot of journalistic articles, chances are you have stumbled upon the marks “i.e.” and “e.g.”. Chances are you probably also never thought you never truly knew what they meant.

The confusion is obvious when you take a good look. First and foremost, we have the dreaded “i.e.”. Most people either pronounce it “I E” or “in example”, both of which are wrong. “i.e.” is actually an acronym for Latin “id est”, literally “that is”. The grammatical sens of a phrase may thus be very different if you interpret it wrong. Besides, “in example” is wrong grammar. You should always use “for example”.

Second but not last is “e.g.”. Much in the same way, “e.g.” is not read by its sounding which is similar to “example”, but rather as the Latin “exempli gratia”, literally “for the sake of an example”. Because of its close meaning, reading “e.g.” as “for example” is generally accepted and can be used in situations which require such a construct.

Very often we overhear Standard in International. The technical definition of international is that it is something pertaining to two or more nations at the same time. As a web site owner, being conscious of your audience is important, and that audience can turn out to be more than just American.

This is why you have to learn to speak internationally, and probably the biggest obstacle is Time Notation, for which there is generally two solutions.

The Standards Solution

One easy way to cater to an international audience, if you happen to have one (Google Analytics is a very good way to find out), is to simply put everything in standard notation.

For example, when announcing an live web event, you could use dates like these: 2010-02-07

This normally confusing notation, is 02 or 07 the month, can never be because it’s part of the IEC standard for dates, so it’s YYYY-MM-DD and because it is the only date format that starts with the year.

However, English isn’t Japanese, and we were conditioned to naming months by their name, and not by numbers, so using the IEC standard notation is not the best for readability because we have to constantly translate the middle number to a month.

The same happens with time. We could use the standard 24:00 clock, but it wouldn’t cater to France which uses an h instead of a colon, like this: 24h.

The Local Solution

One real solution is to take a good look at your audience. Is it international? Etc.
Although you can do that by studying demographic statistics, the language you use is an easy way to determine what standard to use.

For example, French-speaking communities practically never use p.m and a.m with a 12 hour clock (the exception being Canadian French, although the 24 hour notation is still common). Most people in France that have never been exposed to American English will look at you weird if you say p.m. or a.m. as they probably never heard that before.

So, adapting is the key. For example, on AMV-Canada’s web site, I used a mixed representation for the different populations that goes like this for live show: 2 p.m PST, 5 p.m. EST and 22:00 in the UK. While this may look bizarre at first, it is unambiguous as Canadians and Americans will read the part they need easily while skipping a different notation for an piece of information not important to them and the British will do the same by simply reading their version.

It’s also better to avoid writing dates without the month, and to avoid things such as UTC -05 when denoting Eastern Standard Time (EST). You’d be surprised at how many people don’t know what UTC or GMT are, even EST is sometimes not known.

If you’re American, avoid naming web events with TV notations like 8/7c as these are not only majorly unknown to every other English speaking country, but they are also not the same time across the entire United States. 8/7c effectively equals 8 EST, 8 PST, 7 CST and 7 MST, but if you live on the East Cost, you might have meant 8 EST and 5 PST, 7 CST and 6 MST.

However, Local Adapting requires some research into each country’s way of specifying dates and time.