Translations

Hi.

Just 2 very simple questions regarding spanish translation support.

1. CVS translation 100% completed.

I have just translated individual spanish .po files for CVS version of Drupal. I do not have CVS write access yet (I suppose support team is really busy with 4.6 version), so I have decided to post it here in order to upload it into contrib CVS, if you are so kind.

Basic instructions:

Hi

File of language

When?

Regards

Sattam

Hallo to everyone.

I am taking care of the italian translation, and I am quite concerned about translation versioning.
At the moment, we dispose of 4.5.0 translation, 4.5.2 translation and 4.6rc in progress translation.
Translation project only include 4.5.0 and cvs translations. I wasn't able to create a 4.5.2 translation project.
So, how am I supposed to handle translation files? shall I put 4.5.2 translation in 4.5.0 space or what else? if else, what should I do with 4.5.2 translation file? (it is slightly different from 4.5.0 and include many corrections).

A new Turkish translation is available. Nearly strings that will be seen by end user have been translated. some admin strings have not been translated because of lack of time.
You can check this translation on sites below

Yeni bir Türkçe çeviri yaptım. Son kullanıcı tarafından görülebilecek neredeyse tüm stringler çevrildi. Bazı admin kısımlarına zaman eksikliğinden dolayı vakit ayıramadım.
Aşağıdaki sitelerden çevirileri kontrol edebilirsiniz.

One thing I feel lack when it comes to translations are a way to differentiate between strings at different locations.
Currently, Drupal only supports one translation of each "source"-string. But in many languages, words might have different meanings depending on the context.

I have just started thinking about this, but it should be possible to use the function 'debug_backtrace' to something like this:

If this code is added to the t()-function in core, the exact line and file where t('some string') was called from is available to the translator.

        $caller = debug_backtrace();
        $file = basename($caller[0]['file']);
        $line = $caller[0]['line'];

The only thing I fear is that
a) debug_backtrace is a heavy function, and calling it for every t() in drupal would cause a big performance loss.
- But with normal caching this should not be an issue.
b) Many strings that are translated only once today and that are correct, even if they appear many times in many places, must be translated several times.
- This can be handeled by extending the function that does the translation today to something like:
o Get all strings that match 'source'
o If one of these also has a match on module:line - use that
o Or, if we have a match on module - use that and add source + new location + destination to the correct tables
o Or if we only have a match on source - use that and add source + new location + destination to the correct tables
o Or if we do not have a match, return original source and add source + location to the correct tables

I can make a patch for this, but I would like some feedback first, to know if this is something that others agree on.

hello
i want translate drupal to persian
how i can do it
my language is very similar to arabic
encoding of my language utf-8 and direction of my language is right to left

please help me