Translations

I make some module translation for the 4.7 version, I commit all my .po file in the Po directory but when i tray to tag my file I receive:

Hi people,

I'm beginning to use drupal and I have a problem when I want to translate.

My problem is:

- When I export the po file (es.po) it appears the following error:

· The translation import failed, because the file could not be read.
· The translation import of failed.

It can be a problem of the Apache? (I don't Know!!)

PD: Sorry for my bad english.

OK, I'm now the official maintainer of the Hebrew translation project. I've uploaded the new 4.7 translation files, but they are still marked with CVS and the Hebrew translation page still shows the previous version for download.

Questions:
1. How do I mark those files as 4.7.0 translations?
2. How do I convience drupal to generate the 4.7.0 archive for me?

I've tried to use the TortoiseCVS tag command but it fails - no such tag is defined for the repository. What am I missing?

Thanks in advances,

Amnon

I'm using TortoiseCVS

Hi,

I'd like to share this site with you http://www.delimitor.com its about selective translation which you can easily use it to translate any Language File into your own language by button click!

thanx

I've just created an issue for Drupal 4.7 Hebrew translation.

I've just uploaded the Hebrew translation of the drupal 4.7 core to the CVS.
This translation is also used in Drupal.org.il, a site that I've initiated.

Please read the issue and try to answer my questions

Also the hebrew translation page is very old and needs to be updated - who should I write to become the official maintainer?

Thanks

Amnon

i've discovered another slightly tricky issue with the new release system and version numbering schemes for contrib: what should we do about version numbers for core translation releases?

all the core translations are in contrib, and have their own project nodes. we certainly need to allow them to make official releases, just like any other contribs. however, they have slightly different needs and properties than modules, and those could be reflected in their version strings:

• they actually care about the exact version of drupal core. in theory, it shouldn't matter, but in practice, translatable strings can and do change in the middle of a stable release series of core. so, a translation that was 100% for 4.7.3 will in fact be 98% or something for 4.7.4, unless the maintainer updates their translation. we'd like to associate translation releases (and their % status) with a specific version of core, not just the end of a given branch of core.
• they have no need for more than 1 branch for each version of core. modules might want stable vs. development branches of code that's all compatibile with 4.7.x of core, but that makes no sense for translations -- they're not code. ;) no such thing as a "new feature" -- either you translate the strings or you don't.

the way version numbers will work for the rest of contrib will be like this: