Hello Guys!
Today I was looking into my "Translate" directory and noticed that there is a desktop-effects folder, but there is only one po file inside. I would like to know how to make a po file for my language.
Thanks in advance, Igor Pires Soares
Le dimanche 26 novembre 2006 à 01:21 +1000, Chester Cheng a écrit :
Hi Igor,
The .pot file hasn't been prepared by the author. It will be released soon and we can make po files then.
I think there is translation related problems here.
Why hasn't it been made BEFORE FC6 ? Why hasn't it be done at the same time than developing desktop-effects ? Why translation is always seen as second class interest by developers ? Why most translators seem to accept this second class idea ? Why bugzilla bug reports must be opened to force a developer to add translations ?
Question I don't have any answer for ... yet ?
Cheers, Chester
Igor Pires Soares 提到:
Hello Guys!
Today I was looking into my "Translate" directory and noticed that there is a desktop-effects folder, but there is only one po file inside. I would like to know how to make a po file for my language.
Thanks in advance, Igor Pires Soares
(removed -devel-list since this is a -trans-list issue)
O/H Thomas Canniot έγραψε:
Le dimanche 26 novembre 2006 à 01:21 +1000, Chester Cheng a écrit :
Hi Igor,
The .pot file hasn't been prepared by the author. It will be released soon and we can make po files then.
I think there is translation related problems here.
Why hasn't it been made BEFORE FC6 ? Why hasn't it be done at the same time than developing desktop-effects ? Why translation is always seen as second class interest by developers ? Why most translators seem to accept this second class idea ? Why bugzilla bug reports must be opened to force a developer to add translations ?
Question I don't have any answer for ... yet ?
Thomas,
I agree we need to fix our l10n process. I've spoken to some people and the presence of the gap is pretty much known. How can we fix it then?
Here are some first ideas:
1. Start by documenting the need for attention to this matter, for example by getting some numbers of the non-english users (e.g. fedora-brazil is HUGE)
2. List irritations the translators have stated in the past. One example is releases not having up-to-date translations in packages [1].
3. Start having IRC meetings to discuss things, our progress and get people to hang out on the IRC channel more often.
4. Think about electing a Steering committee for the team; check out the DocsProject voting proposal:
http://fedoraproject.org/wiki/DocsProject/Policy/FDSCoElections
5. Start writing guidelines for developers and slowly try to make them happen. A steering committee can help with this by having open communication channels.
6. Open up a wiki page holding links to common/known problems, a bug tracker for translation bugs (is there one?) and start pushing release-blocker bugs for important issues.
7. Get the team closer to the Docs project; this team does a *great* job and the two teams have a lot in common and could share experience, tools etc.
The L10N project shouts "I need resurrection" with all it's strength. So, to have something to hold onto, I copied the above points here:
http://fedoraproject.org/wiki/L10N/Tasks
Ideas, comments, suggestions?
-d
[1]: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207095
Cheers, Chester
Igor Pires Soares 提到:
Hello Guys!
Today I was looking into my "Translate" directory and noticed that there is a desktop-effects folder, but there is only one po file inside. I would like to know how to make a po file for my language.
Thanks in advance, Igor Pires Soares
Dimitris Glezos ਨੇ ਲਿਖਿਆ:
(removed -devel-list since this is a -trans-list issue)
O/H Thomas Canniot έγραψε:
Le dimanche 26 novembre 2006 à 01:21 +1000, Chester Cheng a écrit :
Hi Igor,
The .pot file hasn't been prepared by the author. It will be released soon and we can make po files then.
I think there is translation related problems here.
Why hasn't it been made BEFORE FC6 ? Why hasn't it be done at the same time than developing desktop-effects ? Why translation is always seen as second class interest by developers ? Why most translators seem to accept this second class idea ? Why bugzilla bug reports must be opened to force a developer to add translations ?
Question I don't have any answer for ... yet ?
Thomas,
I agree we need to fix our l10n process. I've spoken to some people and the presence of the gap is pretty much known. How can we fix it then?
Here are some first ideas:
- Start by documenting the need for attention to this matter, for example by
getting some numbers of the non-english users (e.g. fedora-brazil is HUGE)
- List irritations the translators have stated in the past. One example is
releases not having up-to-date translations in packages [1].
- Start having IRC meetings to discuss things, our progress and get people to
hang out on the IRC channel more often.
sure, that is most important to improve our communication between team #fedora-l10n is there, you all are welcome. Let us start on channel
- Think about electing a Steering committee for the team; check out the
DocsProject voting proposal:
http://fedoraproject.org/wiki/DocsProject/Policy/FDSCoElections
- Start writing guidelines for developers and slowly try to make them happen.
A steering committee can help with this by having open communication channels.
+1
- Open up a wiki page holding links to common/known problems, a bug tracker
for translation bugs (is there one?) and start pushing release-blocker bugs for important issues.
+1
- Get the team closer to the Docs project; this team does a *great* job and
the two teams have a lot in common and could share experience, tools etc.
we are already working with docs team, but need more closely and more sharing information/data with team.
The L10N project shouts "I need resurrection" with all it's strength. So, to have something to hold onto, I copied the above points here:
good idea
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dimitris Glezos schreef:
(removed -devel-list since this is a -trans-list issue)
O/H Thomas Canniot έγραψε:
Le dimanche 26 novembre 2006 à 01:21 +1000, Chester Cheng a écrit :
Hi Igor,
The .pot file hasn't been prepared by the author. It will be released soon and we can make po files then.
I think there is translation related problems here.
Why hasn't it been made BEFORE FC6 ? Why hasn't it be done at the same time than developing desktop-effects ? Why translation is always seen as second class interest by developers ? Why most translators seem to accept this second class idea ? Why bugzilla bug reports must be opened to force a developer to add translations ?
Question I don't have any answer for ... yet ?
Thomas,
I agree we need to fix our l10n process. I've spoken to some people and the presence of the gap is pretty much known. How can we fix it then?
Here are some first ideas:
- Start by documenting the need for attention to this matter, for
example by
getting some numbers of the non-english users (e.g. fedora-brazil is HUGE)
- List irritations the translators have stated in the past. One
example is
releases not having up-to-date translations in packages [1].
- Start having IRC meetings to discuss things, our progress and get
people to
hang out on the IRC channel more often.
- Think about electing a Steering committee for the team; check out the
DocsProject voting proposal:
http://fedoraproject.org/wiki/DocsProject/Policy/FDSCoElections
- Start writing guidelines for developers and slowly try to make
them happen.
A steering committee can help with this by having open communication
channels.
- Open up a wiki page holding links to common/known problems, a bug
tracker
for translation bugs (is there one?) and start pushing release-blocker
bugs for
important issues.
- Get the team closer to the Docs project; this team does a *great*
job and
the two teams have a lot in common and could share experience, tools etc.
The L10N project shouts "I need resurrection" with all it's strength.
So, to
have something to hold onto, I copied the above points here:
http://fedoraproject.org/wiki/L10N/Tasks
Ideas, comments, suggestions?
-d
Nice list Dimitris, I totally agree.
I would like to add one more thing: the biggest problem (IMHO) is the fact that the L10N-project is way outside the Fedora devel-space (cvs-wise). Lots of package maintainers know about our efforts here, but just don't see it, because of the fact that they have to use two cvs-accounts / trees. I know the plan is to get ourselves on cvs.fp.org and maybe we should just go for it. So what do we want when we do the migration??
An idea: - -> get hooked up in the Fedora Account System, now people on l10n and docs need 2 accounts to get work done, cut it down to 1 - -> get a seperate cvsroot on cvs.fp.org with only .po / .pot -files. - -> try to get into Jesse Keating's pungi, for l10n-inclusion (not so sure if this is possible, if not just a hook in the build system) - -> set up an sort of sponsor-managed cvs or dir in the cvsroot (as extras, docs) so only language maintainers can commit (this may mean a lot of pain for the maintainer, but gives more control) and those files get into the build system - -> (try to) migrate the web-interface and maybe add an online-translation system to it, so we create a low barrier to the project and thus more contributors + QA - -> hook up a commit-mailinglist (or maybe just this one??) - -> ....
Maybe we could call for a meeting with Fedora Infrastructure and Docs when this list is ready and get this "issue" off our back :)
Bart
- -- Bart couf@fedoraproject.org bart@bercie23.be key fingerprint: 6AAB 544D 3432 D013 776D 3602 ADB6 6B2A D93F 0F93
O/H Bart Couvreur έγραψε:
Dimitris Glezos schreef:
The L10N project shouts "I need resurrection" with all it's strength.
So, to
have something to hold onto, I copied the above points here:
http://fedoraproject.org/wiki/L10N/Tasks
Ideas, comments, suggestions?
-d
Nice list Dimitris, I totally agree.
I'm glad the initial list seems sane to most of you. :)
I have updated the list with some of the ideas dropped on the lists:
http://fedoraproject.org/wiki/L10N/Tasks
The main problem I see right now is that we must all understand that for these issues to be resolved, we should actually work on them. It was a bit surprising to see that nobody has edited the page or subscribed to receive changes on it.
So please people, *get involved*, otherwise these problems will remain problems. If the Translation project wants people to bother helping it, it should start helping itself first.
We can start by breaking the big ideas into smaller tasks that could be handled by 1,2 persons each. The smaller/simpler/modular the better.
An idea: -> get hooked up in the Fedora Account System, now people on l10n and docs need 2 accounts to get work done, cut it down to 1 -> get a seperate cvsroot on cvs.fp.org with only .po / .pot -files. -> try to get into Jesse Keating's pungi, for l10n-inclusion (not so sure if this is possible, if not just a hook in the build system) -> set up an sort of sponsor-managed cvs or dir in the cvsroot (as extras, docs) so only language maintainers can commit (this may mean a lot of pain for the maintainer, but gives more control) and those files get into the build system -> (try to) migrate the web-interface and maybe add an online-translation system to it, so we create a low barrier to the project and thus more contributors + QA -> hook up a commit-mailinglist (or maybe just this one??) -> ....
These sound good and concrete ideas (except the online-translation system). There are people to help out and give information; but someone else should be the coordinator (aka the guy that does the correctly correlates tasks, people and time).
I would suggest to remove them from the "task ideas" list and put them on a schedule table with target dates. This way related efforts (RelEng, Docs, Infrastructure) could help you out where needed to get the above implemented. :)
Maybe we could call for a meeting with Fedora Infrastructure and Docs when this list is ready and get this "issue" off our back :)
+1. I'm sure both of these groups are willing to support us in the organization of our processes. I'm also sure they are not willing to do the coding or the maintenance of them.
-d
Dimitris Glezos (dimitris@glezos.com) said:
Maybe we could call for a meeting with Fedora Infrastructure and Docs when this list is ready and get this "issue" off our back :)
+1. I'm sure both of these groups are willing to support us in the organization of our processes. I'm also sure they are not willing to do the coding or the maintenance of them.
Well,the coding needs done. I do like how:
2. Move CVS from i18n to cvs.fedoraproject.org
is just one small item. ;)
Realistically, what needs done is:
- all translators need fedora accounts - a new group 'fedoratrans', or whatever, needs created - CVS needs copied over - ACLs need set up, pre-check scripts, etc.
And this *completely* leaves out things like reserving and locking files, handling translations for projects in git/hg/etc, and other issues.
Bill
Le dimanche 26 novembre 2006 à 13:54 +0100, Bart Couvreur a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dimitris Glezos schreef:
(removed -devel-list since this is a -trans-list issue)
O/H Thomas Canniot έγραψε:
Le dimanche 26 novembre 2006 à 01:21 +1000, Chester Cheng a écrit :
Hi Igor,
The .pot file hasn't been prepared by the author. It will be released soon and we can make po files then.
I think there is translation related problems here.
Why hasn't it been made BEFORE FC6 ? Why hasn't it be done at the same time than developing desktop-effects ? Why translation is always seen as second class interest by developers ? Why most translators seem to accept this second class idea ? Why bugzilla bug reports must be opened to force a developer to add translations ?
Question I don't have any answer for ... yet ?
Thomas,
I agree we need to fix our l10n process. I've spoken to some people and the presence of the gap is pretty much known. How can we fix it then?
Here are some first ideas:
- Start by documenting the need for attention to this matter, for
example by
getting some numbers of the non-english users (e.g. fedora-brazil is HUGE)
- List irritations the translators have stated in the past. One
example is
releases not having up-to-date translations in packages [1].
- Start having IRC meetings to discuss things, our progress and get
people to
hang out on the IRC channel more often.
- Think about electing a Steering committee for the team; check out the
DocsProject voting proposal:
http://fedoraproject.org/wiki/DocsProject/Policy/FDSCoElections
- Start writing guidelines for developers and slowly try to make
them happen.
A steering committee can help with this by having open communication
channels.
- Open up a wiki page holding links to common/known problems, a bug
tracker
for translation bugs (is there one?) and start pushing release-blocker
bugs for
important issues.
- Get the team closer to the Docs project; this team does a *great*
job and
the two teams have a lot in common and could share experience, tools etc.
The L10N project shouts "I need resurrection" with all it's strength.
So, to
have something to hold onto, I copied the above points here:
http://fedoraproject.org/wiki/L10N/Tasks
Ideas, comments, suggestions?
-d
Nice list Dimitris, I totally agree.
I would like to add one more thing: the biggest problem (IMHO) is the fact that the L10N-project is way outside the Fedora devel-space (cvs-wise). Lots of package maintainers know about our efforts here, but just don't see it, because of the fact that they have to use two cvs-accounts / trees. I know the plan is to get ourselves on cvs.fp.org and maybe we should just go for it. So what do we want when we do the migration??
An idea:
- -> get hooked up in the Fedora Account System, now people on l10n and
docs need 2 accounts to get work done, cut it down to 1
- -> get a seperate cvsroot on cvs.fp.org with only .po / .pot -files.
- -> try to get into Jesse Keating's pungi, for l10n-inclusion (not so
sure if this is possible, if not just a hook in the build system)
- -> set up an sort of sponsor-managed cvs or dir in the cvsroot (as
extras, docs) so only language maintainers can commit (this may mean a lot of pain for the maintainer, but gives more control) and those files get into the build system
And this definitely improves the quality of the translated string.
- -> (try to) migrate the web-interface and maybe add an
online-translation system to it, so we create a low barrier to the project and thus more contributors + QA
I completely aggree, a bit late, with Bart.
From my point of view, I don't think it could be that indispensable to
have the same kind of webapp than Launchpad offers for translation, that is,translation directly from the web browser. I personally don't trust any web browser, their stability depending on the websites you are on.
- -> hook up a commit-mailinglist (or maybe just this one??)
It would be great as well, so as to check for updates.
- -> ....
Maybe we could call for a meeting with Fedora Infrastructure and Docs when this list is ready and get this "issue" off our back :)
Bart
Em Sáb, 2006-11-25 às 19:32 +0000, Dimitris Glezos escreveu:
I agree we need to fix our l10n process. I've spoken to some people and the presence of the gap is pretty much known. How can we fix it then?
Here are some first ideas:
- Start by documenting the need for attention to this matter, for example by
getting some numbers of the non-english users (e.g. fedora-brazil is HUGE)
It is a good start! Fedora has a big audience in Brazil and an active community, but we are losing some space to Ubuntu. That's why we need good translations over here. We, Brazilian Ambassadors, are trying to spread Fedora to a larger audience and it will not be successful if we do not have an understandable user interface.
- List irritations the translators have stated in the past. One example is
releases not having up-to-date translations in packages [1].
In my opinion this is the bigger problem we have by now. I just regret about desktop-effects. This is a major feature of Fedora 6 and we do not even have a .pot file to translate, it was a huge lack of attention with us. It seems to be a small module, it would not demand too much "extra" work.
- Start having IRC meetings to discuss things, our progress and get people to
hang out on the IRC channel more often.
Yep, we have to set meetings in advance in order to people organize themselves. It would be good if people hang out on IRC for a more informal conversation too.
- Think about electing a Steering committee for the team; check out the
DocsProject voting proposal:
http://fedoraproject.org/wiki/DocsProject/Policy/FDSCoElections
- Start writing guidelines for developers and slowly try to make them happen.
A steering committee can help with this by having open communication channels.
+1 Yes Indeed. We need to be represented on an organized way before the hole project.
- Open up a wiki page holding links to common/known problems, a bug tracker
for translation bugs (is there one?) and start pushing release-blocker bugs for important issues.
The important is to let the developers know that this bugs exist and that they are very important to the project. It is a good way to do that.
- Get the team closer to the Docs project; this team does a *great* job and
the two teams have a lot in common and could share experience, tools etc.
+1
The L10N project shouts "I need resurrection" with all it's strength. So, to have something to hold onto, I copied the above points here:
Good initiative Dimitris, lets make it happen!
Regards, Igor
Hi,
El ds 25 de 11 del 2006 a les 19:32 +0000, en/na Dimitris Glezos va escriure:
(removed -devel-list since this is a -trans-list issue)
(I think this is definitely a development issue, we are part of the development process, or should be)
I agree we need to fix our l10n process. I've spoken to some people and the presence of the gap is pretty much known. How can we fix it then?
Here are some first ideas:
- Start by documenting the need for attention to this matter, for example by
getting some numbers of the non-english users (e.g. fedora-brazil is HUGE)
IMO this is irrelevant and reinforces the second class view of translations that Thomas pointed out (i.e. having to justify why translations are important). It's not a matter of how may will use a particular translation, it's that there is no reason not to consider translations during the development and release processes.
- List irritations the translators have stated in the past. One example is
releases not having up-to-date translations in packages [1].
Very true!
I'd add the development cycle of system-config-* (and in general all fedora specific) apps. It'd be good if we were informed in due time before a release is done, so we have time to translate.
Then there is this issue with maintenance releases of Fedora. How do we update translations for FC5? Since we are only given HEAD in CVS, we don't know how to reach older, but maintained, releases.
- Start having IRC meetings to discuss things, our progress and get people to
hang out on the IRC channel more often.
This is a very good idea, specially if developers could be involved (although I reckon they already have a lot of other work to do). In general developers are very cooperative people and sympathetic to translators, but it's not unusual that translations are forgotten during the development process.
- Think about electing a Steering committee for the team; check out the
DocsProject voting proposal:
http://fedoraproject.org/wiki/DocsProject/Policy/FDSCoElections
We're very different from the Documentation Project in the sense that we don't need to decide what to document, or everything the documentation project has to deal with (we basically know what our work is, we are not authors). But we probably need a committee that can make our voices heard in the fedora development/release process, so I think it might be a good idea.
Probably we should first think what we want the committee for (we could start another thread if people agree).
- Start writing guidelines for developers and slowly try to make them happen.
A steering committee can help with this by having open communication channels.
- Open up a wiki page holding links to common/known problems, a bug tracker
for translation bugs (is there one?) and start pushing release-blocker bugs for important issues.
- Get the team closer to the Docs project; this team does a *great* job and
the two teams have a lot in common and could share experience, tools etc.
The L10N project shouts "I need resurrection" with all it's strength. So, to have something to hold onto, I copied the above points here:
http://fedoraproject.org/wiki/L10N/Tasks
Ideas, comments, suggestions?
Very good initiatives and points all of them, although, as I mentioned, I'd remove point 1.
BR, /Josep
Josep Puigdemont (josep.puigdemont@gmail.com) said:
Then there is this issue with maintenance releases of Fedora. How do we update translations for FC5? Since we are only given HEAD in CVS, we don't know how to reach older, but maintained, releases.
If there are FC5 branches in CVS, you should be able to update to them just fine.
For example, if you're in the 'initscripts' branch of CVS, cvs -z3 up -r FC5-branch should just work.
Bill
On 11/27/06, Bill Nottingham notting@redhat.com wrote:
Josep Puigdemont (josep.puigdemont@gmail.com) said:
Then there is this issue with maintenance releases of Fedora. How do we update translations for FC5? Since we are only given HEAD in CVS, we don't know how to reach older, but maintained, releases.
If there are FC5 branches in CVS, you should be able to update to them just fine.
For example, if you're in the 'initscripts' branch of CVS, cvs -z3 up -r FC5-branch should just work.
Ok, thanks Bill, I didn't know these branches existed. We should put this information (branch names, etc) in the wiki somewhere, or in the status pages.
It would also be nice to have status pages for the different maintained releases: FC5, FC6, and rawhide. I don't know how complicated this can be, but I could help out with it if needed.
/Josep
Josep Puigdemont (josep.puigdemont@gmail.com) said:
For example, if you're in the 'initscripts' branch of CVS, cvs -z3 up -r FC5-branch should just work.
Ok, thanks Bill, I didn't know these branches existed. We should put this information (branch names, etc) in the wiki somewhere, or in the status pages.
There's no real standard, though.
It would also be nice to have status pages for the different maintained releases: FC5, FC6, and rawhide. I don't know how complicated this can be, but I could help out with it if needed.
The biggest issue is that not every package has branches; there are some (s-c-tools, mainly) that use the same (or similar) source for all supported releases, while things like initscripts or anaconda have branches.
Bill
Thomas Canniot (thomas.canniot@laposte.net) said:
The .pot file hasn't been prepared by the author. It will be released soon and we can make po files then.
I think there is translation related problems here.
Why hasn't it been made BEFORE FC6 ? Why hasn't it be done at the same time than developing desktop-effects ? Why translation is always seen as second class interest by developers ? Why most translators seem to accept this second class idea ? Why bugzilla bug reports must be opened to force a developer to add translations ?
Question I don't have any answer for ... yet ?
Can't speak to the general cases, but in this case, it's an addition to an upstream package, which makes the translating process tricky, as it requires merging multiple source control repositories.
Bill
Hi,
On Mon, 2006-11-27 at 11:03 -0500, Bill Nottingham wrote:
Thomas Canniot (thomas.canniot@laposte.net) said:
The .pot file hasn't been prepared by the author. It will be released soon and we can make po files then.
I think there is translation related problems here.
Why hasn't it been made BEFORE FC6 ? Why hasn't it be done at the same time than developing desktop-effects ? Why translation is always seen as second class interest by developers ? Why most translators seem to accept this second class idea ? Why bugzilla bug reports must be opened to force a developer to add translations ?
Question I don't have any answer for ... yet ?
Can't speak to the general cases, but in this case, it's an addition to an upstream package, which makes the translating process tricky, as it requires merging multiple source control repositories.
For those who don't know, normally the way we do this is we put the desktop file in the redhat-menus package (which is translated on elvis) and install the file into /usr/share/desktop-menu-patches. Then, we ship a symlink in, e.g., the compiz package from the file to /usr/share/applications.
--Ray
Ray Strode (rstrode@redhat.com) said:
Can't speak to the general cases, but in this case, it's an addition to an upstream package, which makes the translating process tricky, as it requires merging multiple source control repositories.
For those who don't know, normally the way we do this is we put the desktop file in the redhat-menus package (which is translated on elvis) and install the file into /usr/share/desktop-menu-patches. Then, we ship a symlink in, e.g., the compiz package from the file to /usr/share/applications.
But desktop-effects has more strings than just the desktop file.
Bill
On Mon, 2006-11-27 at 11:57 -0500, Bill Nottingham wrote:
Ray Strode (rstrode@redhat.com) said:
Can't speak to the general cases, but in this case, it's an addition to an upstream package, which makes the translating process tricky, as it requires merging multiple source control repositories.
For those who don't know, normally the way we do this is we put the desktop file in the redhat-menus package (which is translated on elvis) and install the file into /usr/share/desktop-menu-patches. Then, we ship a symlink in, e.g., the compiz package from the file to /usr/share/applications.
But desktop-effects has more strings than just the desktop file.
Ah right...We should just upstream it at elvis, I guess.
--Ray
On Tue, 2006-11-28 at 16:54 -0500, Soeren Sandmann wrote:
Ray Strode wrote:
But desktop-effects has more strings than just the desktop file.
Ah right...We should just upstream it at elvis, I guess.
Desktop Effects is already checked into elvis.
Since we're on the subject, it was pointed out to me the other day that the desktop-effects source is missing copyright and authorship statements. We can assume Red Hat owns the copyright, but it would be nice to know who wrote it too.
- ajax
Dear Translators,
Compiz is a very cool stuff in Fedora Core. To translate this package, please (in your translate/ folder) do:
cvs -z9 co po_desktop-effects
You'll see the desktop-effects.pot file in the desktop-effects/ directory. Your file can be generated from it.
Regards, Chester Cheng
於 二,2006-11-28 於 16:54 -0500,Soeren Sandmann 提到:
Ray Strode wrote:
But desktop-effects has more strings than just the desktop file.
Ah right...We should just upstream it at elvis, I guess.
Desktop Effects is already checked into elvis.
Soren
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-trans-list
Thanks Chester, this is what I was looking for ;)
Regards, Igor
Em Qui, 2006-11-30 às 01:20 +1000, Chester Cheng escreveu:
Dear Translators,
Compiz is a very cool stuff in Fedora Core. To translate this package, please (in your translate/ folder) do:
cvs -z9 co po_desktop-effects
You'll see the desktop-effects.pot file in the desktop-effects/ directory. Your file can be generated from it.
Regards, Chester Cheng
On Tue, 2006-11-28 at 16:54 -0500, Soeren Sandmann wrote:
Ray Strode wrote:
But desktop-effects has more strings than just the desktop file.
Ah right...We should just upstream it at elvis, I guess.
Desktop Effects is already checked into elvis.
Is there no upstream effort to provide such a capplet / control panel as part of say... compiz? It seems very wrong to me that each distribution is doing their own thing here. Besides, if this lived on cvs.gnome.org it would probably already be translated into a myriad of languages already...
Am I missing something?
David
Hi,
i've added the Catalan translation to desktop-effects, but I'm not sure if I have to notifiy the developers of desktop-effects that a new language is available. Do we have to file a bug report to ensure it is added to the package?
Regards.
2006/11/29, David Zeuthen david@fubar.dk:
On Tue, 2006-11-28 at 16:54 -0500, Soeren Sandmann wrote:
Ray Strode wrote:
But desktop-effects has more strings than just the desktop file.
Ah right...We should just upstream it at elvis, I guess.
Desktop Effects is already checked into elvis.
Is there no upstream effort to provide such a capplet / control panel as part of say... compiz? It seems very wrong to me that each distribution is doing their own thing here. Besides, if this lived on cvs.gnome.org it would probably already be translated into a myriad of languages already...
Am I missing something?
David
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-trans-list