Genitive/possessive 's via XLIFF - xliff

is there a way to determine whether a genitive s has to be appended to a person's representation (i.e. the name).
For example, in English, it is
Petra's cape
Thomas' cape
Liz' cape
(the latter one is only AFAIK because it's pronounced with a trailing s without actually having one); whereas in German, it would be
Petras Umhang (cape)
Thomas' Umhang
Liz' Umhang
What would be the best way to handle this via XLIFF?
Thanks and best regards!

Related

Address form fields for a japanese address

I am building a small application for an english speaking client in Japan. As part of the app, users need to be able to enter their address. Unfortunately, I can't find any reference for how addresses are usually handled in an online form.
I know that there are different combinations of wards/prefectures/cities; do these all usually have their own field in a database? Is it standard for all of that to go into a general "city" type of field? What's the standard UI for this sort of thing?
The Universal Postal Union has compiled info on address formats in different countries. See also an unofficial guide to postal addresses.
But as a rule, internationalization of software typically means that for postal addresses, you avoid imposing any specific format. Instead, you would use a free-form text input area, of sufficient size. There are often many forms of addresses used in a country (and Japan is no exception), and normally you need not enforce any specific format – instead, you expect people to know their own address and how to enter it so that postal services can understand it.
it depends on what you have to do with the address:
if you have to:
check for obligatory fields
validate fields, or
query for city, prefecture, postal code, etc.
then you should use separate fields. UI: a form with text-inputs (and maybe even menus).
do not use more fields than necessary, so if you don't have any of the mentioned needs, just use a text-field (UI: textarea).
The first part of a Japanese address is easy: Todofuken will either be 2 or 3 characters, followed by either "都","道","府" or "県". Where it gets tricky is the rest of the address since smaller areas don't always divide their cities neatly.
What I've seen to make this easier is using the postal code to render the address. The bad news is that I haven't seen any of this in Ruby but I have seen it in other languages so hopefully this will help.
This site is only in Japanese, but maybe you can download the code and check it out:
http://www.kawa.net/works/ajax/ajaxzip2/ajaxzip2.html
There's also this add-in for Excel that converts addresses. The code may be helpful to you:
http://office.microsoft.com/ja-jp/excel-help/HP010077514.aspx
Hope this helps.

Can NSLocale's NSLocaleCountryCode key be directly mapped to a TLD?

in my app i need to open a website with the corresponding TLD for that country. Lets say google.com, google.de, etc...
But i don't know which country codes the're specifically using in NSLocale's dict. Can i assume that the lowercase version of NSLocaleCountryCode can be appended as TLD?
Regards, Erik
From Locales Programming Guide:
The region code is defined by ISO
3166-1
ISO 3166-1 is not equivalent to top level domains, at least not in all cases. For instance: .co.uk ≠ GB
On the other hand, there are only six or so exceptions. See the Wikipedia entry.

camel case method names

I understand the reason to camel case variable names, but I've always wondered why you would camel case a method name? why is it toString() and not ToString()? What purpose does it serve?
A lot of conventions say you capitalize the first letter of types (classes, structs, enums, etc.), and use lowercase otherwise (functions, members, etc.).
If you follow that convention, you can then tell just by looking that MyStruct.MyType refers to a nested type, and MyStruct.myData refers to some form of data, and MyStruct.myFunc() refers to a function call.
We use lower-case on the first letter to save a little ink in our printouts.
It's just a convention. Like all conventions they only serve to, in the minds of their creators, make code easier to read and maintain.
Because that's what the original designers of Java liked.
Because to be consistent you'd have to capitalize the first letter of every method name, and then you have to hit the Shift key that many more times in a day.
Since camel cases capitalizes the first letter of each word to substitute spaces, we are left with the challenge of how to differentiate a capitalized title, like we would in English for a proper noun. As a solution to this, the first word in a camel case identifier is capitalized to indicate the title or identifier is capitalized.
In the case of programming, it seems appropriate to most, to capitalize the name of a class, but not the name of its methods. In practically it provides a nice distinction between the two.
Over the years programming has evolved to have a lot of conventions, while many are very different, there is much that people tend to agree on. However, you will find that the answers to "why questions", such as the one you posted, are not always rooted in something entirely concrete.
I don't think there is any reason, these are just conventions and everyone might have his own.
If you want a function
write();
that takes less effort (one less SHIFT keypress) than
Write();
However, if you're writing to a file, you need to distinguish the words. Hence
writeToFile();
is marginally more efficient (and still consistent with the first example)
Usually you tend to follow the one that your framework uses. So Java developers tend to use lowercase to start, and .NET developers tend to use uppercase to start.
If you haven't already read the wikipedia page, it contains everything you could ever possibly want to know on camel case, including its history.
CamelCase (also spelled "camel case")
or medial capitals is the practice of
writing compound words or phrases in
which the elements are joined without
spaces, with each element's initial
letter capitalized within the
compound.
And
One theory for the origin of the camel
case convention holds that C
programmers and hackers simply found
it more convenient than the standard
underscore-based style.
C programmers lazy? I doubt that very much.
Pascal case
The first letter in the identifier and the first letter of each subsequent concatenated word are capitalized. You can use Pascal case for identifiers of three of more characters.
For example: BackColor
Uppercase
All letters in the identifier are capitalized. Use this convention only for identifiers that consist of two or less letters, or abbreviations, such as BSU and UCS. In the example below, IO and UI are the uppercase identifiers, whereas System follows the Pascal capitalization style because the length is greater than two.
For example: System.IO; System.Web.UI
Camel case
The first letter of an identifier is lowercase and the first letter of each subsequent concatenated word is capitalized.
For example: backColor
The following Link summarizes the capitalization rules and provides examples for the different types of identifiers and items within your Web application/project.Hopefully this link will helpful for you
https://dotnetprod.bsu.edu/AdminConsole/Documentation/ASPDotNet/CodingStyle/NamingConventions/Capitalization.aspx
A friend told me that a study showed that people could read code easier if Types were camel case, with an upper case first letter, and variables were done_like_this. It certainly does make the difference between types and variables jump out.
I've never known which was clearer for function names. I've generally considered capitalizing the first letter, but after reading this I think it might be more readable not to to distinguish between type names and method names (yes, in some languages a method signature is a type, but you know what I mean!)

How to get list of all countries and the encryption standard which is not allowed for that country

I want to know the list of all countries and the encryption standard not allowed for that country.
Example: For some country encryption is not allowed. and for some country encryption level should not be grater than 64 bit.
Thanks
Sunil Kumar Sahoo
The resource you are looking for is the Crypto Law Survey.
I do not believe such a list exists.
You need to research for each country and build such a list on your own. The best way is of course let a lawyer investigate that for you.
Anyway, what do you need it for? If it's a web application that resides on servers in a country X you only need to comply with that country requirements. The fact that people can access your application from anywhere in the world will not be your concern.
the ones I know of
Russia
Ukraine
Crimea
Egypt
Kazakhstan
Israel
Turkey
China
Pakistan
Check with a lawyer (as this data would come from the laws of that specific country, which tend to change); then make a list, e.g.
<country id="US">
<bannedcipher type="rot13" />
</country>
and keep it up to date (that's the hard part). AFAIK, there's no reliable way to get this list programatically; also, the encryption allowed may vary according to the use (e.g. "In Elbonia, everybody except the military is hereby banned from using XOR").

How relevant are url names in non english speaking countries?

If I have a commercial site belonging to a Japanese company which will use Katakana or Kanji (non ASCII characters) for the keyword they wish to obtain good search results in google, does it still matter to put the closest english word on the site DNS Name?
like:
if the search word is "homepage" in Katakana: ホームページ
Will the the DNS name have an impact on the results?
Is it better, does it have any effect having a DNS Name which includes "homepage"?
Thanks,
Ric
What name will bring higher hit counts is kind of an art, not a science.
Since the IDN (International Domain Names) support is still weak in a lot of tools I would think that a Japanese DNS name would bring less hits than an English one.
On another side, in my experience the content and proper tagging of the content is way-way more important than the domain name itself to attract traffic.
DNS international domains are translated to unreadable ascii, so I guess it doesn't make sense to use it for SEO.