Developping for the translation industry RSS 2.0

 Tuesday, December 22, 2009

Web-addressAfter a long wait, ICANN (the Internet Corporation for Assigned Names and Numbers) has finally taken some steps to make web-addresses that are not based on the Latin alphabet a reality. In other words, the Internet is going to get a lot more friendlier for a major part of the global population.

A proposal for the use of non-English characters in web addresses is up for consideration. The proposed change is called Internationalized Domain Names or IDNs. At present non-English characters can only be used in a section of a web address. Once IDNs become a reality, native web-users from Japan, China, Russia, Arabia and Korea and many other nations will be able to fully browse through the net in their very own languages. The most obvious result of this development would be a significant leap in internet usage across many parts of the world. Another result of this development will be a growing need for translation services and localization because of the rise of cultural and linguistic diversity within the online population.

From the press release:

"The coming introduction of non-Latin characters represents the biggest technical change to the Internet since it was created four decades ago," said ICANN chairman Peter Dengate Thrush. "Right now Internet address endings are limited to Latin characters – A to Z. But the Fast Track Process is the first step in bringing the 100,000 characters of the languages of the world online for domain names."

Though they have not been put to use on a global scale, IDNs are not a new concept, on the contrary they been hotly debated for around a decade. There has been a lot of doubt about whether IDNs as a concept could work, however thanks to countries like China and the fact that over half of the 1.6 billion internet users are not familiar with Latin characters, ICANN has been led to consider IDN.

The organization has been testing the translation technology that can convert from one character set to another and deliver the correct address for over a couple of years now and is confident about its success. ICANN will be reviewing this historic proposal at the 36th International Public Meeting in Seoul and if the body approves it then we could be seeing the use of IDNs by mid of the coming year.


Other posts :

Facts and Figures about the Language Industry

The Best Damn Web Marketing Checklist, Period!

How to generate random numbers within a T-SQL query

Domain registration and one full year of Web hosting for Free!

Free software tools for students

Big news in the translation industry

Tuesday, December 22, 2009 10:40:43 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] -
News | Language Industry
 Tuesday, December 15, 2009


Here are some interesting facts and numbers about the language industry.

Language Services Market

  • The language services market is predicted to reach US$25 billion by 2013.
  • North American telephone interpreting providers account for 85% of the combined revenue of the Top 15 global providers.
  • The average year-over-year growth rate of the top 20 translation companies in 2007 was 26.68%.
  • The total market for outsourced interpreting services stood at US$2.5 billion in 2007, with telephone interpreting worth US$700 million.
  • 70% of LSPs employ between one and 10 people, 11% employ between 20 to 99, and the rest employ 101 or more.  Only six firms worldwide employ more than 1,000 people.
  • Nearly 90% of companies outsource some or all of their translation and localization work.
  • In 2005, there were around 4,000 translation companies with more than five employees in the world; 450 of those were based in the United States.

Translation Technologies

  • 20% of medium-to-large LSPs offer a house brand of translation management.
  • 67% of language buyers say that a vendor’s automation capabilities are important.
  • Content that reaches 200,000 words (roughly 400 U.S. letter-size pages) triggers the need for a translation memory.


  • About 40% of translation buyers regularly buy from five or more suppliers, while 20% buy from only two.
  • Almost one-tenth of software firms fully outsource localization work to a language services provider, specialty coding house or offshore developer.
  • Only 26% of companies can formally measure and calculate the return on their localization investment.
  • 44% of translation buyers stayed with their vendors for five years or more, with the rest citing far longer relationships.
  • Three-quarters of the typical purchaser of translation services have been buyers for six years or less.

Global Marketing

  • It would take 83 languages to reach 80% of all the people in the world, and over 7,000 languages to reach everyone.
  • Websites offered in only one language can address at most 30% of the total online population.
  • Translating into 50 languages provides access to almost 96% of the world’s online residents.
  • 72.4% of consumers say they would be more likely to buy a product with information in their own language.
  • 56.2% of consumers say that the ability to obtain information in their own language is more important than price.
  • 72.1% of the consumers spend most or all of their time on sites in their own language.
  • English, French, Italian, German, Spanish and Japanese add up to 88% of the addressable online market.
  • More than 99% of what people write, say, or generate never leaves the language in which it was created.
  • Websites tailored linguistically and transactionally to the residents of one country can address, at most, 20% of the total world online population.
  • Over 70% of software suppliers localize new releases.
  • Only 12 of the top 100 global brands and just four of the top 50 U.S. online retailers translated a significant part of their corporate websites in Spanish.


Source: Common Sense Advisory

Tuesday, December 15, 2009 1:34:59 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0] -
Business | General | Language Industry
 Monday, December 14, 2009

Physical security:

  • Ensure the physical security of each SQL Server, preventing any unauthorized users to physically accessing your servers.


  • Ensure that your SQL Servers are behind a firewall and are not exposed directly to the Internet
  • Avoid creating network shares on any SQL Server.
  • Only install required network libraries and network protocols on your SQL Server instances.


  • Only give SQL Server service accounts the minimum rights and permissions needed to run the service. In most cases, local administrator rights are not required, and domain administrator rights are never needed. SQL Server setup will automatically confgure service accounts with the necessary permissions for them to run correctly, you don’t have to do anything.
  • Run each separate SQL Server service under a different Windows domain account.
  • Use strong passwords for all SQL Server login accounts.
  • Turn on login auditing so you can see who has succeeded, and failed, to login.
  • Remove sample databases from all production SQL Server instances.
  • Add operating system and SQL Server service packs and hot fixes soon after they are released and tested, as they often include security enhancements.

Users and permissions management:

  • Assign the SA account a very obscure password, and never use it to log onto SQL Server. Use a Windows Authentication account to access SQL Server as a sysadmin instead.
  • When possible, use Windows Authentication logins instead of SQL Server logins.
  • Remove user login IDs who no longer need access to SQL Server.
  • Remove the guest user account from each user database.
  • Never grant permission to the xp_cmdshell to non-sysadmins.
  • Don’t use the SA account, or login IDs who are members of the Sysadmin group, as accounts used to access SQL Server from applications.
  • Give users the least amount of permissions they need to perform their job.
  • Use Windows Global Groups, or SQL Server Roles to manage groups of users that need similar permissions.
  • Don’t grant permissions to the public database role.


Other posts:

What is LDAP injection?

The T-SQL LoginProperty function in SQL Server 2005

How to: Use Active Directory to authenticate users

How to put log4net configs outside of the application configuration file

Monday, December 14, 2009 1:12:56 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0] -
 Thursday, December 03, 2009

In today’s economy we are all trying to strive for more; more profit, more customers, more everything. We constantly look for new and ground breaking ways to achieve our goals in the quickest manner possible. Well, below are some mistakes that every manager should never make unless they want to kill their company. From The New York Times:

  1. Hiring without checking up on the persons background. This is probably one of the most important mistakes not to make. Always look as far into someone’s background as you can get, you never know what they may be hiding and how far back it goes.
  2. If you are a company that provides company vehicles for your employees, please make sure that each and every one of them are insured properly. Under insured or wrongly insured drivers who happen to get into an accident can be a huge money problem for your company.
  3. Make sure that you have the proper controls set up. By this I mean anti theft systems, surveillance cameras and anti virus systems on your computer. Someone breaking into your building and stealing everything after they trash your property or set fire to your building as well as someone hacking into your computer system and possibly your companies bank account can be devastating.
Thursday, December 03, 2009 3:22:56 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0] -
 Tuesday, December 01, 2009

Stoney deGeyter compiled the Best Damn Web Marketing Checklist, Period! It contains 400 items in over twenty-three topics of:

  • Domain names and URLs
  • Browser issues
  • Site logo
  • Design considerations
  • Architectural issues
  • Navigation
  • Content
  • Content Appearance
  • Links and buttons
  • Home page
  • About Us page
  • Contact Us page
  • E-Commerce considerations
  • Product pages
  • Basket page
  • Mini baskets
  • Checkout process
  • Login and My Account pages
  • Help and FAQ pages
  • Forms and errors
  • Site search
  • Privacy and Security pages
  • Site map

The posting is from 2008, so it doesn’t include anything on social medias, but it’s great nonetheless. You can download a PDF version here: The Best Damn Web Marketing Checklist.


Other posts

8 easy tips to drive traffic from search engines to your site

What Are Customers Saying About You Online?

Tuesday, December 01, 2009 12:02:52 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0] -
 Monday, November 23, 2009

LDAP Injection is an attack used to exploit web based applications that construct LDAP statements based on user input. When an application fails to properly sanitize user input, it’s possible to modify LDAP statements using a local proxy. This could result in the execution of arbitrary commands such as granting permissions to unauthorized queries, and content modification inside the LDAP tree. The same advanced exploitation techniques available in SQL Injection can be similarly applied in LDAP Injection.

The key to exploiting injection techniques with LDAP is to manipulate the filters used to search in the directory services. Using these techniques, an attacker may obtain direct access to the database underlying an LDAP tree, and thereby to important corporate information. This can be even more critical because the security of many applications and services relies on single sign-on environments based on LDAP directories.


In a page with a user search form, the following code is responsible to catch input value and generate a LDAP query that will be used in LDAP database.

 <input type="text" size=20 name="userName">Insert the username</input> 

The LDAP query is narrowed down for performance and the underlying code for this function might be the following:

 String ldapSearchQuery = "(cn=" + userName + ")";

If the variable userName is not validated, it could be possible accomplish LDAP injection, as follows:

  • If a user puts “*” on box search, the system may return all the usernames on the LDAP base
  • If a user puts “jonys) (| (password = * ) )”, it will generate the code bellow revealing jonys’ password ( cn = jonys ) ( | (password = * ) )

How to protect against these attacks?

INPUT VALIDATION. This will never be said enough: input validation is the best way to protect against most injection-type attacks. Whitelist validation is always your best bet. The idea is that you should check that the data is one of a set of tightly constrained known good values. For example, for the username field above, the input should accept only alphanumeric characters.


Other posts:

The T-SQL LoginProperty function in SQL Server 2005

BusinessWeek hit by SQL Injection attack

How to: Use Active Directory to authenticate users

How to set NTFS permissions using C# 2005

Monday, November 23, 2009 3:31:41 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0] -

I use log4net in every applications I build that needs to have some sort of log. 

Most of the examples on the log4net site puts the configuration right in the App.config/Web.config file for the example application. Since they are simply example and not real-life scenarios, that’s not necessarily the best way to do it. For example, you may have a single log4net.config that you want to use in several projects or you simply want to stick log4net.config somewhere else to make those config files more readable.

The magic bit that at least I can't easily find and always forget is:

If you add an appSettings key called "log4net.Config" you can put an app-relative path to an external log4net.config file in there and everything will automatically configure itself using that.

It looks like this:

<?xml version="1.0"?>
    <add key="log4net.Config" value="log4net.config" />

That example puts the log4net.config file right in the root of the application. You could specify "config/log4net.config" to put it in a "config" subfolder. You don't even have to call the XmlConfigurator.Configure method or mark your assembly with an XmlConfiguratorAttribute or anything. Some voodoo magic happens in the background and it just works.


Other posts :

How to enumerate the Domain Controllers in the current Domain in C#

How to Create User Accounts in Active Directory using C#

How to restart a Windows service using C#

How to set NTFS permissions using C# 2005

Monday, November 23, 2009 10:21:14 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] -
.NET | General | Tools
 Friday, November 20, 2009

There are many ways to generate random numbers in SQL Server. Here are some scripts that will let you accomplish this.

Method 1 : Generate Random Numbers (Int) between Rang
---- Create the variables for the random number generation

---- This will create a random number between 1 and 999
SET @Lower = 1 ---- The lowest random number
SET @Upper = 999 ---- The highest random number
SELECT @Random = ROUND(((@Upper - @Lower -1) * RAND() + @Lower), 0)
SELECT @Random

Method 2 : Generate Random Float Numbers
+ (
DATEPART(ss, GETDATE()) * 1000 )

Method 3 : Random Numbers Quick Scripts

---- random float from 0 up to 20 - [0, 20)
-- random float from 10 up to 30 - [10, 30)
SELECT 10 + (30-10)*RAND()
--random integer BETWEEN 0
AND 20 - [0, 20]
----random integer BETWEEN 10
AND 30 - [10, 30]
SELECT 10 + CONVERT(INT, (30-10+1)*RAND())

Method 4 : Random Numbers (Float, Int) Tables Based with Time

DECLARE @t TABLE( randnum float )
DECLARE @cnt INT; SET @cnt = 0
WHILE @cnt <=10000
@cnt = @cnt + 1
+ (
DATEPART(ss, GETDATE()) * 1000 )
randnum, COUNT(*)
GROUP BY randnum

Method 5 : Random number on a per row basis

---- The distribution is pretty good however there are the occasional peaks.
---- If you want to change the range of values just change the 1000 to the maximum value you want.
---- Use this as the source of a report server report and chart the results to see the distribution
SELECT randomNumber, COUNT(1) countOfRandomNumber
SELECT ABS(CAST(NEWID() AS binary(6)) %1000) + 1 randomNumber
FROM sysobjects) sample
GROUP BY randomNumber
ORDER BY randomNumber


Other posts :

How to convert dates in T-SQL

How to remove leading zeros within an SQL Query

How to insert a file in an image column in SQL Server 2005


Friday, November 20, 2009 10:21:08 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] -
Code Snippet | SQL
 Thursday, June 11, 2009

The difference between a 301 and a 302 is that a 301 status code means that a page has permanently moved to a new location, while a 302 status code means that a page has temporarily moved to a new location.

As you may know, there aren't too many situations where a 302 is the appropriate choice. How often have you temporarily moved a page? It's much more common to move pages permanently. However, for lazy webmasters, it is a lot easier to create 302 redirects than 301. You can simply use Javascript or a meta tag to create a 302. With Windows servers and IIS, creating a 301 redirect is pretty straitforward. In the website properties or the page properties, you select the following screen. You simply have to select the “A redirection du a URL” option and you have to make sure that the “A permanent redirection for this resource” checkbox is checked. If it isn’t checked, a 302 redirect will be issued by IIS.


Using 302 redirects is a dangerous practice. Search engines don't like this redirection type because it is a common strategy that spammers use to get more of their domains up in search engine results. Another reason to use 301 redirects instead is that then your URLs maintain their link popularity. If you set up 302 redirects, Google and other sites that determine popularity ratings assume that the new link is eventually going to be removed. After all, it's a temporary redirect. So the new page doesn't have any of the link popularity associated with the old page. It has to generate that popularity on its own.

If you're changing your site's domain name, you should never use a 302 redirect. This almost screams "spammer" and is a good way to get all your domains blocked from Google and other search engines. If you have several domains that all need to point to the same place you should use the 301 server redirect. This is common practice for sites to buy additional domains with spelling errors ( or for other countries (, and then redirect them to the primary Web site. As long as you use a 301 redirect, you won't be penalized in search engines.

Other posts :

8 easy tips to drive traffic from search engines to your site

What Are Customers Saying About You Online?

Thursday, June 11, 2009 10:48:53 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] -

About the author/Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2019
Stanislas Biron
Sign In
Total Posts: 135
This Year: 0
This Month: 0
This Week: 0
Comments: 1
All Content © 2019, Stanislas Biron