aMSN Forums
February 11, 2012, 01:00:42 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: New forum for aMSN !!
 
   Home   Help Search Login Register  
Pages: [1]
  Print  
Author Topic: A feature request for tranlations -- opinions needed  (Read 7800 times)
hillingar
Newbie

Offline Offline

Posts: 30


View Profile
« on: July 08, 2007, 11:12:41 pm »

Hi all,

I am the Turkish translations maintainer (Ilgar Eroglu) for aMSN. After some discussion with my friend Oktay Dogangun, one of the other translation contributors, we decided to propose a change for the current language key replacement system (more precisely, a change in the way the trans proc in lang.tcl works). But considering that some other languages may be having similar issues, we want to get opinions from people speaking different languages to come up with a system that would satisfy as many people as possible. Here is the background:

There are two kinds of problems we're having with Turkish translations. They are:

1) The word order is subject-object-verb, so there are a few strings which get translated rather awkwardly to fit into the English scheme. An example is (from amarok plugin config window):

Get songs each (in milliseconds) $refresh

where $refresh is the number of milliseconds. In Turkish, you have to write

Sarkiyi her $refresh (milisaniyede) al

At this point we are not pressing a resolution for this one, because a complete fix may require language-specific rearrangement of text entry boxes etc., which is somewhat cumbersome. I just wanted it to be known that such an issue exists, and perhaps someone can find a solution which is not too hard to implement.

2) The second and more frequent problem that we encounter in Turkish translations is about suffixes. Turkish is agglutinative, which means everything is done with suffixes (no prefixes, no prepositions) but there are also the so-called vowel and consonant harmony rules, which mean that the suffix can take several forms to preserve sound harmony with the root. As an example, the suffix "den" (meaning "from") can take the 4 forms den/dan/ten/tan.

In the current system, we have to translate a key like "from $1" into "$1'den", which is the wrong replacement about 3/4 of the time. We can think of two ways to fix this:

a) (If lang = tr) Make the the trans proc scan for substrings of the form "$i'den" and replace the "den" part with the correct suffix. This preserves compatibility with the current langfiles.

b) The current implementation of trans calls subst with -nocommands, which means we can't embed Tcl commands into the translated strings. If this were allowed we could translate the key to "$1'[tr_suffix "den"  $1] " where tr_suffix represents a proc that will pick the correct suffix for the word $1. This is a technically simpler fix  but requires a new lang file format.

---------

So the question to the developers is: How plausible do you find the idea of modifying the trans proc in a way to solve the 2nd problem mentioned above?

And to other non-English speakers: Are there similar issues in your own language that you think should be dealt with?
Logged
kakaroto
Administrator
Super Power User
*****
Offline Offline

Posts: 9424


View Profile WWW
« Reply #1 on: July 09, 2007, 06:55:06 am »

Hi,
I'll be brief
1) you already know that we use $1 $2 $x... for arguments, so if the string were to be translated completely we wouldn't do : "[trans get_songs] $refresh" but we would do "[trans get_songs $refresh]" and the translation would have "$1" in it. In that case, you can put the $1 wherever you want. Problem is, like you said, with entry boxes, where rearranging the entry box would be too cumbersome. In that case, I wonder what other applications do, or what the HIG suggests. You could take a look there. What I would suggest is to simply translate into : "Sarkiyi her 'X' (milisaniyede) al : " and let the user figure out that the entry next to the string is meant to replace the 'X'.
2) wow, that's way more complicated than an X to Y translation. I don't understand though what you mean with the 'den/dan/ten/tan' thing.. how would "from" take one of those 4 forms ? which one should be used depends on what ? on the value of $1 or something? you talk about 'preserve sound harmony' are you saying like in english "a car" vs. "an airplane" ? or something different ?
anyways..
a) nope, too specific and wouldn't make much sense to have that...
b) yes, but then it would break all other languages, don't forget you might have [] chars in other languages that shouldn't act as function calls.

I see two solutions :
1) create a new 'very generic' language file format, preferably in XML as it is extendable and would avoid any more problems like the ones you just suggested in case other special cases appear in the future. In which case, as you probably know, the team is very inactive lately and I would highly doubt that anyone would do this. I see you seem pretty experienced in Tcl (or at least, you have basic knowledge), so I would suggest you come up with a new lang format, in xml, I don't know, maybe something like :
Code:

<key name="from_x">
   <translate lang="en">
      <text>From $1</text>
   <translate lang="tr">
      <text>$1'%1</text>
      <suffix keyword="%1" rule="turkish_suffixes" type="from">
          <form>den</form>
          <form>dan</form>
          <form>ten</form>
          <form>tan</form>
       </suffix>
    </translate>
</key>

<suffix_rules name="turkish_suffixes">
   <code argument="type">
      switch {$type} {
        from {
          if {$1 == "..." } { .... }
        }
       }
   </code>
</suffix_rules>



Where you could set up rules for suffixes, and have code manage them, with custom arguments, etc... you see, that's the power of XML and with something like that, we could avoid any future problems with other languages.
Now... what this means is :
1) you would need to figure out something 'unbreakable' and fully extendable, and that does everything you need,
2) it must be easy to manage
3) it must be easy for new translators to join.. right now, it's easy "open notepad, write the key, and translate it", imagine a tutorial for something like that, I'm pretty sure noone would want to help translate amsn anymore..
4) you would have to code it
5) we need to stay backward compatible with older lang file versions
6) autoupdater of lang files must be adapted
7) choose whether we keep one file per lang or one file for all langs (in my above example, you see there's a "<translation lang="..">" which suggests one file for all translations)
Cool probably make a script to automatically convert all lang files to new lang file format
9) would resolve many problems to have a script in which we would add the new keys for a lang, and it updates the XML, this way, translators can keep doing their job the same way without learning this new xml file format...
10) time...

Now, that was my first idea, it would be good, but cumbersome, complicated, would scare off new translators, etc... I don't like it that much but it would be the most 'extensible' thing.
My second idea would be :
2) a new plugin named "turkish something" (lang fix, or whatever you want to call it), which would simply hook the trans key, and do the modification you need. If anyone is bothered, he could use the plugin and see the perfect translations he wants, otherwise, too bad... just use the "most neutral" suffix...

p.s.: damn it, I NEVER succeed in being "brief".

thx for your time and for the effort Smiley
Logged

KaKaRoTo
hillingar
Newbie

Offline Offline

Posts: 30


View Profile
« Reply #2 on: July 09, 2007, 07:39:03 am »

Hi kakaroto, thanks for the reply,

Actually many of the ideas you mentioned came up in the discussion with my friend. Let me  explain a bit more:

Quote
we wouldn't do : "[trans get_songs] $refresh" but we would do "[trans get_songs $refresh]"...


As you said, the main problem here is the placement of text boxes etc. Since this kind of obstacle doesn't come up too often, we can ignore that at the moment; most of the time we can rephrase the sentences in somewhat awkward (but grammatically correct)  ways that fit the given scheme.

Quote

I don't understand though what you mean with the 'den/dan/ten/tan' thing..


It's like this: Here are 4 nouns:

ok
ay
ek
il.

If I add the suffix -den (="from") to these, they become

oktan
aydan
ekten
ilden

"e" changes to "a" to preserve vowel harmony and the consonant "d" sharpens to "t" to preserve consonant harmony. The rules are simple and fixed (Turkish is a %99.9 regular language) so given a root word you can easily tell what form the suffix should take.

Quote
a) nope, too specific and wouldn't make much sense to have that...
b) yes, but then it would break all other languages, don't forget you might have [] chars in other languages that shouldn't act as function calls.


I agree with (a). For (b), we would only need to change the [ and ] to \[ and \] in the current langfiles.

Quote
I see you seem pretty experienced in Tcl (or at least, you have basic knowledge),


I'm a Tcl n00b really, I just have the very basic knowledge. I agree that creating a generic XML format would take considerable effort and restructuring. I have neither the time nor the knowledge to undertake that. One of the reasons for proposing the removal of -nocommands was that it is the one which requires the least amount of change (but still, requires a small lang format change).

Quote
a new plugin named "turkish something" (lang fix, or whatever you want to call it), which would simply hook the trans key, and do the modification you need.


I thought of that, too. I just wasn't sure that I can hook the trans keys. If this is possible, it may be possible to write a plugin which can work with the current lang files. I may ask for a little technical help for the hooking part though Smiley. I will look into this suggestion. Thanks,

Ilgar
Logged
kakaroto
Administrator
Super Power User
*****
Offline Offline

Posts: 9424


View Profile WWW
« Reply #3 on: July 09, 2007, 07:46:55 am »

cool.
The 'emotes' plugin was written as a "proof of concept" to show *how* you can easily hook any function from amsn. It ended up being used as a real plugin,but it was actually just a proof of concept of the hooking algorithm, you can look there, it's easy.. as simple as :
Code:
rename trans original_trans
proc trans {key args} {
  global lang
  set result [eval original_trans $key $args]
  if {$lang == "tr" } {
    set result [regsub {....} $result]
  }
  return $result
}

first two lines do all the job of hooking :p you just need to make sure your 'deinit' proc of the plugin does the opposite job (rename trans to "" (to destroy the proc) and call [rename original_trans trans]).
Logged

KaKaRoTo
hillingar
Newbie

Offline Offline

Posts: 30


View Profile
« Reply #4 on: July 09, 2007, 07:54:43 am »

Now THAT'S cool !!! I apologize for not noticing that before -- I have contributed to a couple of plugins already but I hadn't gone that far into aMSN coding (little time left from school Sad). Oktay has already implemented part of the necessary functionality into his modified Amarok plugin so hopefully we will have the entire code ready in the not so far future. Thanks again!!!
Logged
OktayD
Newbie

Offline Offline

Posts: 14


View Profile
« Reply #5 on: July 09, 2007, 04:09:11 pm »

Hi all, I'm Oktay Dogangun.

Quote from: "kakaroto"
1) create a new 'very generic' language file format, preferably in XML as it is extendable and would avoid any more problems like the ones you just suggested in case other special cases appear in the future.

In the discussion with Ilgar, we also thought of a semi-xml format for lang files, i.e. one may write tags in any lang file just in part, the whole file doesnt need to be in an xml format:
Code:
get_file <suff_tr den>$source</suff_tr> $file indirildi.

[where it says 'get_file $file downloaded from $source']
This is quite like eval without -nocommand option. We may write several tags that correspondes to a tcl command.

It will also support languages that has relative prefixes or moods (changing the form of the word) or other grammatical rules:
Code:
<pref_xx prefix_name>$1</pref>
<mood_xx mood_name>$1</mood>

As an example, I think Russian has more complicated noun-cases.

The function part of these tags may be concluded in lang.tcl or so.

BTW, the most of the assian languages are turkic/altaic languages that has exactly same harmonies (Mongolian, Hungarian, Azerbaijani, Korean, Japaneese, etc). Maybe such a feature would be a way to (re)introduce these languages in aMSN.

Thanks for your time.
Logged
hillingar
Newbie

Offline Offline

Posts: 30


View Profile
« Reply #6 on: July 15, 2007, 04:49:37 am »

Oktay and I wrote the code, and it seems to work well. But we have trouble making it into a plugin by replacing amsn's trans function.

First of all, we are aware of a (sort of dirty) hack using the technique in emotes.tcl. Emotes.tcl does not use the rename command as suggested above by kakaroto, but I think rename should be the right thing to use really. So, we try this: Our new "trans" fuction is "::evircevir::trans". In the plugin init, we call

Code:

proc Init { directory } {
::plugins::RegisterPlugin "evircevir"
rename ::amsn::trans ::amsn::originaltrans
rename ::evircevir::yenitrans ::amsn::trans
}


But the first rename command gives the error:

Code:
[20:17:46] core: Initialization of plugin evircevir with evircevir::Init failed
can't rename "::amsn::trans": command doesn't exist
can't rename "::amsn::trans": command doesn't exist
    while executing
"rename ::amsn::trans ::amsn::originaltrans"
    (procedure "::evircevir::Init" line 3)
    invoked from within
"::${namespace}::${init_proc} [file dirname $file]"


If we put the first rename call (but not the second of course) to the very beginning of the plugin source file, it gives the same error.

As test calls, if we make calls to [trans ...] in Init or at the beginning of the file they work, but ::amsn::trans doesn't. Trying to rename "trans" instead of "::amsn::trans" doesn't work either, the renaming works ok but right after that amsn freezes with errors saying it can't find the command trans.

So the question is: How come it can not find ::amsn::trans although it apparently is working?

If we define our new trans function as proc ::amsn::trans then it successfully replaces the old one (but then of course we can't revert to the original after deinit). If I comment out the first rename and leave the second one only, it doesn't give any errors but it doesn't seem to replace the original trans function either.
Logged
JeeBee
Power user
*
Offline Offline

Posts: 139


View Profile
« Reply #7 on: July 17, 2007, 10:38:18 am »

proc trans is implemented in lang.tcl
It is not in a namespace called amsn, so
its name is just ::trans and not ::amsn::trans

Good luck
Logged
hillingar
Newbie

Offline Offline

Posts: 30


View Profile
« Reply #8 on: July 17, 2007, 10:58:47 am »

Hi JeeBee,

I tried your suggestion and it works Smiley, thank you... I think I actually tried the correct thing at some stage but it must have failed due to another mistake, making me search for something else.
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!