I try to find a glossary of abap related terms.
I tried this page, but it failed with "sapterm.com:50026 not reachable" http://www.sapterm.com/
I tried this page to search for "data element" but the search has a nice progress bar, but after waiting for some minutes, still no result: https://help.sap.com/viewer/product/GLOSSARY/?q=data%20element
For me it is important to have the matching English and German terms, since we have international customers.
I don't want to translate these terms myself, and using a online dictionaries return false results often.
I would like to know the official translation which is used by sap itself.
Transaction code SAPTERM should be more comfortable, not sure how up to date it is but it is worth a try:
Simply log in with your SAP user and select your language explicitely as German (DE)
or
If you want to browse the technical documentation on ABAP then run the transaction ABAPDOCU once logged in and search for your term.
Once found, remember the path in the navigator tree on the left hand side.
Log in in a separate window but this time in German (DE) and run the transaction ABAPDOCU. Follow the path you got once searching for the English term.
Voilà! You have found the German term for your wanted English term.
The official ABAP documentation always contained an accurate glossary of terms, for all ABAP versions.
Here are the links to the glossary of ABAP 7.52 (with approximately 1.300 entries) :
English
German
The correct URL is
sapterm.com:50026/sap/bc/webdynpro/sap/sterm_webaccess?sap-client=000
Related
I read a few papers about machine translation but did not understand them well.
The language models (in Google translate) use phonetics and machine learning as best as I can tell.
My question then becomes is it possible to convert an Arabic word that is phonetically spelled in English to translate the users intended Arabic word?
For instance the word 'Hadith' is an English phonetic of the Arabic word 'حديث'. Can I programmatically go from 'Hadith' to Arabic?
Thanks the Wiki article, there's an entire field of work in the area of Transliteration. There was a Google API for this that was deprecated in 2011 and moved to the Google Input Tools service.
The simplest answer is Buck Walter Transliteration but at first glace a 1:1 mapping doesn't seem like a good enough idea.
I am going to try to see if there's a way to hack the Google Input tools and call it even at CLI level because their online demo works very well
I have a service that allows user's (admins) to change the terminology the site uses. My designer wants me to use the format "A Group". The problem is, for some terminology, it should be "An" not "A".
Is there any way to reliably detect which to use? What about localization?
I can brute force it and get 90% of the way by checking the first letter for consonant vs vowel. That won't work for all words though. And that doesn't cover any language except English.
In my opinion you've got only 2 ways:
1- You need to check the first letter and process all the sentence by checking its letters to see if there is any non-English letters.
2- Provide a dictionary of English nouns then you can easily check your word to find if it needs an "a" or "an".
Although the "a versus an" issue is very specific, what you're describing here is a natural language processing issue. Essentially you are being asked to write code that generates a grammatically correct piece of text.
I think you should try to to explain the implications to the designer, especially if you end up localizing in other languages. Your time is probably better spent working on your app's business logic than on language processing.
Basically I'm looking for a search engine that searches through a given database. The content will be text being searched.
You will probably want to use a service such as Solr. The easiest way to get started using it is to find a 'cloud' based version, such as Websolr. However, the solution will depend on what language you wish to use when programming your site.
Solutions depend somewhat on language:
1. For java/c#, you have lucene/solr
2. for python you have haystack
You could do text search in the DB directly via LIKE/ILIKE, but the performance depends on DB.
Iconfinder was coded specifically for icon search and at the time (launched in 2007) there were no scripts that worked well for this.
Building a search engine like Iconfinder is not rocket science. I think the hardest part is getting the SQL tuned and figure out how to rank the content. At the moment I collect data about impressions and downloads and calculate a value from that. The icons' rank is based on this value (download/impression) and how well keywords match the tags for the given icon.
I'm creating an English translation for a program written in German (i.e. all strings within tr("...") are German). Users who are in a non-English non-German locale will probably want to see the English translation, but with the program as it is now they will see German.
There are some ways to solve this problem:
Check if it's a German locale and force to English otherwise.
Present an option to the user.
Make the programmers change their source code to English.
What is considered best-practice for internationalizing where the source code is not in English?
These are two separate questions.
The best practice is to not use any kind of hard-coded string in the sources.
Strings should be stored in external files and loaded by ID.
But what you have there does not sound like the best practice. Might be too much work to get it there.
What you describe (the tr("...") stuff) sounds like gettext (or something similar).
That approach for gettext (and similar libraries) is that "the stuff in the sources is the ultimate fallback", used if the strings for the desired language are not present.
In this case I would go with "Present an option to the user."
You can't assume the user knows English.
Real example: in Switzerland the official languages are Italian, German, French and Romansh. If I ask for French and it is not present, then the next best option is probably German, not English. I Canada the official languages are French and English, so if I as for French and is not available, the next best option is probably English.
I think the best option is asking the user (during installation probably).
Change the source to English is too costly and not worth it. I live in Brazil, we have tons of codes in Portuguese and translating to English wan't necessary one time (we do make software to english speakers). Unless you have a client that requires you to do so (usually when you are selling the source also).
Hope it helps
OK, so I guess the three options are:
Recompile the program with translated strings.
This is fraught with danger as you'll end up with two copies of the source. Bug-fixes in one will need to be done in the other. And then, what happens if you need French? Italian? Spanish? The only advantage of this approach is that it's feasible for a non-developer to do the work. (Just about.)
Resource out the strings, and automatically check what the UI locale is on load.
Here the strings are replaced with GetResource("key") or similar. On load the program automatically translates to the user's culture. This might work, but I know plenty of German-speakers who have English-language culture installed on their PCs but who would prefer German language programs at some points.
Resource out the strings and give the user the choice on load
In general it's always best to give the user control. This might be a prompt on load, although if the application is used often this can be an annoyance. Perhaps a balance is to ask the user during installation for their preference and then give then an option in a dialog to later change this setting.
Note, by the way, that translation is not localisation. For instance: number formats are quite different in Germany (e.g. 1.233,44) from English (e.g. 1,233.44). Icons and suchlike often have national characteristics.
I am designing a localized web app. I am leaning on auto-detect browser language setting. But I notice a number of respectable sites asking the user to select a language. Is there any usability issue you know of (from actual experiences out there) with just auto-detecting user language?
Thanks.
Give me a choice
Remember my choice
Use the auto-detect as default
Make transition easy
In many situation I prefer or even need the "original" over my local one, bad translations or different content being the major reason.
If you register multiple domains, you can base your auto-detect on that: When foo.com redirects me to foo.de, or otherwise shows me a german interface, it is actively ignoring my choice to go to foo.com.
MSDN did insist on showing me atrocious automatic translations and ALWAYS made me click to go to the readable, understandable english one (that's a step up: when they introduced it, the default selection for changing the language was something like Afrikaans).
Make transition easy: i.e. make it easy to go to the counterpart of the current page in a different language. Amazon often succeeds when I change ".com" to ".de", but then it fails to lead me to the german translation of the item. That's not always possible, as that requires each local view having the same structure and a 1:1 page mapping. But generally, you have to weight above requirements against other constraints of the project.
[edit] MSDN got better now :)
I would suggest to autodetect the language and display the site in this language or the default languge (probably english) if the translation is not available. Additionally present the user with a selection of languages on top or bottom of your page. The names of the languages should be written in the target language.
Don't do it like that: English, German, Italian.
But: English, Deutsch, Italiano.
Obviously there is the usability problem that you might detect a language that the user doesn't understand. How are you going to do the detection? Don't think everybody has their browser set to the correct language. IP-Adresses are also a very bad indicator for the users language.
Practical example: YouTube tried to convince me for a week or so to use the Japanese version, though I can't read Japanese. Not very helpful. Microsoft is also determined to serve me automatically translated versions of there documentation when I just want to read the English one.
So don't try to tell your users which language they're supposed to prefer, let them decide for themselves.
I really hate non-configurable auto-detection because a lot of applications are translated more than imperfectly. I would rather read perfect English than bad Russian. For example, some terms do not translate in a reasonable way, and trying to translate everything makes localized version faintly ridiculous.
Also some applications can not translate new features fast enough, leading to a mixed language.
So I always prefer to have a choice, and choose the version that is native to the application author -- for the best language (unless it is a language I do not know).
Update:
One situation when it has gone beyond ridiculous is DB2 (or its client tools, not sure), which forced me to install a Russian version, but all errors in this version were shown as "???????? ??? ??? ??".
Yes: at work, we have a Windows XP deployed with 'English' language (because we have worldwide site and only one kind Windows to deploy with only one kind of settings when it comes to language).
Yet all out applications must run in French. The auto-detect feature alone would not be enough for an appropriate display of the labels.
Sometimes when you are trying to describe something to a user over the phone and you are in a different location, it is very annoying when you are both looking at the same URL, but see different results. You might even go so far as to include the language in the URL similar to how wikipedia does it (e.g. en.wikipedia.org).
Also sometimes a user will be on a friend's computer and try to access a website but won't see it in their preferred language, because of the language settings on the computer.
I think the best solution would be to allow the user to override the setting, but default it to the auto-detected language.
I agree that the auto-detect is not enough.
Not many users know the settings for selecting their language. Therefore the settings will often be the default and therefore incorrect (for non-english users).