From: Eliovir <el...@gm...> - 2012-11-27 21:45:42
Attachments:
esperanto.tbz2
|
Hi, I've updated the launchpad code to retrieve the translation made throw Rosetta <https://translations.launchpad.net/enlightenment> You can find as attachment the archive of all available translations for Esperanto. It fits the source code directories. Maybe some LINGUAS files must be corrected. Thanks Olivier for the Esperanto translators in Launchpad. |
From: Massimo M. <mai...@gm...> - 2012-11-27 22:24:24
Attachments:
signature.asc
|
Eliovir, il 27/11/2012 22:45, ha scritto: > Hi, > > I've updated the launchpad code to retrieve the translation made throw Rosetta > <https://translations.launchpad.net/enlightenment> hi olivier, please consider that the files provided by launchpad are quite old, and many of them are from packages that are not in svn anymore or are now merged in e17. anyway I merged your file for e17 with a current pot file, and committed it along with all files related to existing modules. -- Massimo Maiurana GPG keyID #7044D601 La fede e' credere in cio' che sai non essere vero [Mark Twain] |
From: Eliovir <el...@gm...> - 2012-11-28 07:16:21
|
Hi Massimo, > please consider that the files provided by launchpad are quite old, and many > of them are from packages that are not in svn anymore or are now merged in e17. I updated the templates on 26-11-2012, from the SVN source. You can see the last updates at https://code.launchpad.net/~e17-users/enlightenment/l10n-import Launchpad is writing the .po files only once a day, so the .po files can be a little older than the SVN sources. I'll think about updating the .po before sending to the list. > anyway I merged your file for e17 with a current pot file, and committed it > along with all files related to existing modules. thanks Olivier |
From: Massimo M. <mai...@gm...> - 2012-11-28 17:29:22
Attachments:
signature.asc
|
Eliovir, il 28/11/2012 08:16, ha scritto: > I updated the templates on 26-11-2012, from the SVN source. so, for what I understand, currently launchpad needs someone who update its templates and its po files, am I right? is there some way to make it an automatic task, or to find someone who take care of keeping it in sync with svn, as it was with damned lies? as of now there are several templates that are not in svn anymore. for example etk and ewl are hystory now, elitaire is in /BROKEN, notification is part of e17 now. having someone who mantains our presence in launchpad would be great, it could ease the work for many translators. otherwise I think I'll remove ts reference to launchpad translations in our wiki. -- Massimo Maiurana GPG keyID #7044D601 La fede e' credere in cio' che sai non essere vero [Mark Twain] |
From: Eliovir <el...@gm...> - 2012-11-28 22:55:03
|
28/11/2012 18:29, Massimo Maiurana : > Eliovir, il 28/11/2012 08:16, ha scritto: > >> I updated the templates on 26-11-2012, from the SVN source. > > so, for what I understand, currently launchpad needs someone who update its > templates and its po files, am I right? You're right. Until now Aron Xu did this. I proposed to help him. > is there some way to make it an automatic task, or to find someone > who take care of keeping it in sync with svn, as it was with damned lies? I write a little script to create the templates from the sources and put them into launchpad. It can be launch daily, automatically, if it works. I need to know if you found errors with my archive, and what they were. > as of now there are several templates that are not in svn anymore. for example > etk and ewl are hystory now, elitaire is in /BROKEN, notification is part of > e17 now. I marked etk, ewl and elitaire as inactive translations. I'll remove this translations from the export. > having someone who mantains our presence in launchpad would be great, it could > ease the work for many translators. otherwise I think I'll remove ts reference > to launchpad translations in our wiki. I think you can leave it. I can do the work myself, but I need an overview for the obsolete templates (as you said for etk, ewl, elitaire). If translators of other languages want to use Launchpad as the place to translate, a work must be done to merge the translations from SVN with those of Launchpad. Does the use of msgmerge can do the job? Eg. : msgmerge file_from_svn.po file_from_launchpad.po Best regards Olivier |
From: Sérgio M. <sma...@gm...> - 2012-11-29 10:09:05
|
I would prefer not having Portuguese translation at launchpad. Launchpad is well known for adventurers translating this and that just because they want. Or at least change maintainers. At this point enlightenment is translated by Portuguese Launchpad Translators. This team has 2 members. I´ve applied to it about 1 year ago. No replies. 44 members to be approved. If launchpad is the way to go we should create enlightenment dedicated teams. People that are in sync with developement and know what to do. Regards 2012/11/28 Eliovir <el...@gm...> > 28/11/2012 18:29, Massimo Maiurana : > > Eliovir, il 28/11/2012 08:16, ha scritto: > > > >> I updated the templates on 26-11-2012, from the SVN source. > > > > so, for what I understand, currently launchpad needs someone who update > its > > templates and its po files, am I right? > > You're right. Until now Aron Xu did this. I proposed to help him. > > > is there some way to make it an automatic task, or to find someone > > who take care of keeping it in sync with svn, as it was with damned > lies? > > I write a little script to create the templates from the sources and put > them into launchpad. It can be launch daily, automatically, if it works. > I need to know if you found errors with my archive, and what they were. > > > as of now there are several templates that are not in svn anymore. for > example > > etk and ewl are hystory now, elitaire is in /BROKEN, notification is > part of > > e17 now. > > I marked etk, ewl and elitaire as inactive translations. > I'll remove this translations from the export. > > > having someone who mantains our presence in launchpad would be great, it > could > > ease the work for many translators. otherwise I think I'll remove ts > reference > > to launchpad translations in our wiki. > > I think you can leave it. I can do the work myself, but I need an > overview for the obsolete templates (as you said for etk, ewl, elitaire). > > If translators of other languages want to use Launchpad as the place to > translate, a work must be done to merge the translations from SVN with > those of Launchpad. > > Does the use of msgmerge can do the job? > Eg. : msgmerge file_from_svn.po file_from_launchpad.po > > Best regards > > Olivier > > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > INSIGHTS What's next for parallel hardware, programming and related areas? > Interviews and blogs by thought leaders keep you ahead of the curve. > http://goparallel.sourceforge.net > _______________________________________________ > Enlightenment-intl mailing list > Enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-intl > -- Sérgio Marques |
From: Massimo M. <mai...@gm...> - 2012-11-29 12:38:06
Attachments:
signature.asc
|
Eliovir, il 28/11/2012 23:54, ha scritto: > I write a little script to create the templates from the sources and put > them into launchpad. It can be launch daily, automatically, if it works. > I need to know if you found errors with my archive, and what they were. there were no errors in your archive, al the po files were good. > I think you can leave it. I can do the work myself, but I need an > overview for the obsolete templates (as you said for etk, ewl, elitaire). ok, I will write a list of translatable packages. > If translators of other languages want to use Launchpad as the place to > translate, a work must be done to merge the translations from SVN with > those of Launchpad. > > Does the use of msgmerge can do the job? > Eg. : msgmerge file_from_svn.po file_from_launchpad.po AFAIK msgmerge is intended to update the first file with strings from the second. to merge two or more files together you'd need msgcat. -- Massimo Maiurana GPG keyID #7044D601 La fede e' credere in cio' che sai non essere vero [Mark Twain] |
From: Massimo M. <mai...@gm...> - 2012-11-29 12:41:06
Attachments:
signature.asc
|
Sérgio Marques, il 29/11/2012 11:08, ha scritto: > I would prefer not having Portuguese translation at launchpad. Launchpad is > well known for adventurers translating this and that just because they want. your files are always updated, usually there nothing to translate in them so I guess that nobody will pick them from launchpad ;) -- Massimo Maiurana GPG keyID #7044D601 La fede e' credere in cio' che sai non essere vero [Mark Twain] |
From: Sérgio M. <sma...@gm...> - 2012-11-29 13:02:54
|
2012/11/29 Massimo Maiurana <mai...@gm...> > Sérgio Marques, il 29/11/2012 11:08, ha scritto: > > I would prefer not having Portuguese translation at launchpad. Launchpad > is > > well known for adventurers translating this and that just because they > want. > > your files are always updated, usually there nothing to translate in them > so I > guess that nobody will pick them from launchpad ;) > > Let´s hope so. Regards -- Sérgio Marques |
From: Massimo M. <mai...@gm...> - 2012-11-29 18:17:33
Attachments:
signature.asc
translatables.txt
|
Massimo Maiurana, il 29/11/2012 13:37, ha scritto: > ok, I will write a list of translatable packages. > list attached :) -- Massimo Maiurana GPG keyID #7044D601 La fede e' credere in cio' che sai non essere vero [Mark Twain] |
From: Eliovir <el...@gm...> - 2012-11-29 20:36:53
|
Le 29/11/2012 19:17, Massimo Maiurana a écrit : > Massimo Maiurana, il 29/11/2012 13:37, ha scritto: > >> ok, I will write a list of translatable packages. >> > > list attached :) Thanks, Searching the gettext function _, D_, N_, I've found other programmes: enjoy, envision, excessive, empower, enki, ephoto, eve E-MODULES-EXTRA/everything-shotgun E-MODULES-EXTRA/eweather E-MODULES-EXTRA/itask E-MODULES-EXTRA/mpdule Should I remove them? NB: I use mpdule, it's working without bug. Olivier |
From: Massimo M. <mai...@gm...> - 2012-11-29 23:21:56
Attachments:
signature.asc
|
Eliovir, il 29/11/2012 21:36, ha scritto: > Thanks, > > Searching the gettext function _, D_, N_, I've found other programmes: I know, but none of them looks localized. some lacks a Makefile in /po, some lacks other necessary files. > Should I remove them? yes, until someone fixes them. > NB: I use mpdule, it's working without bug. all of them are working, they just can't be localized AFAIK :) -- Massimo Maiurana GPG keyID #7044D601 La fede e' credere in cio' che sai non essere vero [Mark Twain] |
From: Eliovir <el...@gm...> - 2012-11-30 07:19:36
|
Thanks, Le 30/11/2012 00:21, Massimo Maiurana a écrit : > Eliovir, il 29/11/2012 21:36, ha scritto: >> Searching the gettext function _, D_, N_, I've found other >> programmes: > > I know, but none of them looks localized. some lacks a Makefile in >> /po, some lacks other necessary files. > >> Should I remove them? > > yes, until someone fixes them. I've done the changes This is the list of available templates: https://translations.launchpad.net/enlightenment/trunk/+templates I'll do a script later to compress those translations into an archive. Olivier |
From: Massimo M. <mai...@gm...> - 2012-11-30 12:09:55
Attachments:
signature.asc
|
Eliovir, il 30/11/2012 08:19, ha scritto: > This is the list of available templates: > https://translations.launchpad.net/enlightenment/trunk/+templates great, thanks! :) this way everybody can contribute even without knowing anything about generating templates. how do you generate your templates? if I'm not wrong you talked about a script, if it's really so can you share it? -- Massimo Maiurana GPG keyID #7044D601 La fede e' credere in cio' che sai non essere vero [Mark Twain] |
From: Olivier . <el...@gm...> - 2012-12-01 08:41:50
|
Yes, you can see the script. I've put it in the code. The direct link to see it is http://bazaar.launchpad.net/~e17-users/enlightenment/l10n-import/view/head:/update-e17-l10n.sh And to export the translations into an archive: http://bazaar.launchpad.net/~e17-users/enlightenment/l10n-export/view/head:/language-archive.sh. NB: - Launchpad updates the translations in the export branch once a day. - I do not put the script in a cron task on my computer. I'm waiting a little bit to see if all is OK. (and currently, I'm away) If you see something wrong, do not hesitate to tell me or to write a bug report ;) Olivier 2012/11/30 Massimo Maiurana <mai...@gm...> > Eliovir, il 30/11/2012 08:19, ha scritto: > > > This is the list of available templates: > > https://translations.launchpad.net/enlightenment/trunk/+templates > > great, thanks! :) > this way everybody can contribute even without knowing anything about > generating templates. > > how do you generate your templates? if I'm not wrong you talked about a > script, if it's really so can you share it? > > -- > > Massimo Maiurana GPG keyID #7044D601 > > La fede e' credere in cio' che sai non essere vero > [Mark Twain] > > > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > TUNE You got it built. Now make it sing. Tune shows you how. > http://goparallel.sourceforge.net > _______________________________________________ > Enlightenment-intl mailing list > Enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-intl > > |
From: Massimo M. <mai...@gm...> - 2012-12-01 12:37:58
Attachments:
signature.asc
|
Olivier ., il 01/12/2012 09:41, ha scritto: > If you see something wrong, do not hesitate to tell me or to write a bug report ;) > AFAICS the only thing that should be enhanced is the way xgettext is called. in every /po dir there is, or there should be, a Makevars file containing options for xgettext. unfortunately that file should be parsed with some sed/awk magic to set some variables for your xgettext invocation, it can't just be sourced as it is in sh because variable are in the format "VARIABLE_NAME = options" and not "VARIABLE_NAME='options'". currently you execute xgettext this way: xgettext --keyword=_ --keyword=D_ --keyword=N_ --from-code=UTF-8 \ --foreign-user --default-domain=$DOMAIN --files-from=po/POTFILES.in \ --output=$DEST/$DOMAIN.pot the best bet would be so to parse Makevars and use this command instead: xgettext --default-domain=$DOMAIN --add-comments=TRANSLATORS: \ $XGETTEXT_OPTIONS --files-from=po/POTFILES.in \ --copyright-holder='$COPYRIGHT_HOLDER' \ --msgid-bugs-address='$MSGID_BUGS_ADDRESS' --output=$DEST/$DOMAIN.pot if it can't be done, at least let's give xgettext all possibile -k options just to make sure all messages are catched: xgettext --keyword=_ --keyword=D_:1 --keyword=d_:1 --keyword=P_:1,2 \ --keyword=dP_:1,2 --keyword=N_ --keyword=NP_:1,2 \ -keyword=EVRY_PLUGIN_BASE:1 --keyword=EVRY_ACTION_NEW:1 --from-code=UTF-8 \ --foreign-user --default-domain=$DOMAIN --files-from=po/POTFILES.in \ --output=$DEST/$DOMAIN.pot while we're at it, I just found that empower actually produces a pot, but it doesn't update po's and has no LINGUAS file. I don't know if its l10n actually works, it would be great if someone could try it but in the meantime I've committed your eo.po and my it.po, so I guess you can add it in the list of translatable packages :) -- Massimo Maiurana GPG keyID #7044D601 La fede e' credere in cio' che sai non essere vero [Mark Twain] |
From: Olivier . <el...@gm...> - 2012-12-01 17:23:50
|
My initial idea was to run autogen.sh and then using the Makefile. But sometimes autogen.sh fails, due to the lack of libraries. So I decided to use the same process for all packages, directly using xgettext. Thanks for the complete default command line, I'll use it as default process. I tried the command line below to produce a SH script with the parameters, ready to be sourced. It seems to work. sed -e 's/ = /="/g' -e 's/$/"/g' -e 's/\\"//g' -e 's/ ="$/=""/g' Makevars | grep = | grep -v DOMAIN= > params.sh I'll work later on this, as I'm way from my computer. I've enabled empower in Rosetta. Olivier |
From: Olivier . <el...@gm...> - 2012-12-04 12:37:54
|
I've modified my script to use your command, and updated the templates. It seems that there are some changes in the directories. Ecore was renamed to to efl/ or is deplaced to IN-EFL/? |
From: Massimo M. <mai...@gm...> - 2012-12-04 16:38:40
Attachments:
signature.asc
|
Olivier ., il 04/12/2012 13:37, ha scritto: > It seems that there are some changes in the directories. Ecore was renamed to > to efl/ or is deplaced to IN-EFL/? /IN-EFL is the tree for the 1.7.x version of the libraries, and it will end when the version 1.7.2 will be released. e-0.17 will depend on 1.7.2, so I think they'll be released together on 21 december. the various libraries in svn are being merged, one after the other, in a unified package, which is /efl. the last merged library is ecore. there will never be an ecore package in svn anymore, and the same will happen for efreet (and maybe for elementary too). we'll just have an efl.pot to translate :) -- Massimo Maiurana GPG keyID #7044D601 La fede e' credere in cio' che sai non essere vero [Mark Twain] |
From: Carsten H. (T. R. <ra...@ra...> - 2012-12-04 23:06:46
|
On Tue, 04 Dec 2012 17:38:26 +0100 Massimo Maiurana <mai...@gm...> said: > Olivier ., il 04/12/2012 13:37, ha scritto: > > > It seems that there are some changes in the directories. Ecore was renamed > > to to efl/ or is deplaced to IN-EFL/? > > /IN-EFL is the tree for the 1.7.x version of the libraries, and it will end > when the version 1.7.2 will be released. e-0.17 will depend on 1.7.2, so I > think they'll be released together on 21 december. actuy no - IN-EFL is simply historical reference of the trees as they were just prior to merge into efl. this helps vincent and everyone fix up efl tree problems quickly as we have an instant reference to the "last working state in trunk". the 1.7.x (1.7.2) is a totally separate branch based on the 1.7.0 release with JUSt bugfixes (no new features). the IN-EFL trees are actual "development" trees with lots of additions and changes as well. :) > the various libraries in svn are being merged, one after the other, in a > unified package, which is /efl. the last merged library is ecore. there will > never be an ecore package in svn anymore, and the same will happen for efreet > (and maybe for elementary too). we'll just have an efl.pot to translate :) correct. except for now elementary won't go in. we have some.. technical problems to solve first. e_dbus won't go in either. edbus will, as will eio, edje, and efreet. eeze probably needs to be there too. i'd like to see emotion go in too. ethumb, e_dbus and elm are issues. e_dbus because its being superseded by edbus and so we need to migrate to it (but e_dbus will never be killed until we do efl 2.0 - it just will be separate). ethumb depends on e_dbus and needs to migrate to edbus to be able to go in. elm also depends on e_dbus and ethumb. in addition we have some other wonderful fun bits like efl webkit (outside of efl) - it depends on efl, but not elm. but elm depends on webkit (optional) so we have a circular dep here. for now the best thing to do is keep elm out until we have a clear and clean solution to this. the only other thing - evas_generic_loaders. i'd like this to be in, but since it was separated for license as well a stability reasons, i'm currently on the fence as to if it can be put in without there being a license issue. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Massimo M. <mai...@gm...> - 2012-12-05 10:14:50
Attachments:
signature.asc
|
Carsten Haitzler (The Rasterman), il 05/12/2012 00:02, ha scritto: >> /IN-EFL is the tree for the 1.7.x version of the libraries, and it will end >> when the version 1.7.2 will be released. e-0.17 will depend on 1.7.2, so I >> think they'll be released together on 21 december. > > actuy no - IN-EFL is simply historical reference of the trees as they were just > prior to merge into efl. ok, I misunderstood what it was and what its purpose was :) however it will be dropped at some point, won't it? I'm asking because I think it doesn't worth it to keep its translations up to date, am I right? >> the various libraries in svn are being merged, one after the other, in a >> unified package, which is /efl. the last merged library is ecore. there will >> never be an ecore package in svn anymore, and the same will happen for efreet >> (and maybe for elementary too). we'll just have an efl.pot to translate :) > > correct. except for now elementary won't go in. we have some.. technical > problems to solve first. e_dbus won't go in either. edbus will, as will eio, > edje, and efreet. eeze probably needs to be there too. i'd like to see emotion > go in too. I'm seeing that eio is already there. it doesn't need to be translated though, AFAIK the only localized libs are ecore and efreet, so when efreet will get in the /efl tree we'll need to have its messages included in efl.pot (which currently is just the old ecore.pot renamed). -- Massimo Maiurana GPG keyID #7044D601 La fede e' credere in cio' che sai non essere vero [Mark Twain] |
From: Daniel J. S. <seo...@gm...> - 2012-12-05 04:35:02
|
Daniel Juyung Seo (SeoZ) On Dec 5, 2012 8:07 AM, "Carsten Haitzler" <ra...@ra...> wrote: > > On Tue, 04 Dec 2012 17:38:26 +0100 Massimo Maiurana <mai...@gm...> said: > > > Olivier ., il 04/12/2012 13:37, ha scritto: > > > > > It seems that there are some changes in the directories. Ecore was renamed > > > to to efl/ or is deplaced to IN-EFL/? > > > > /IN-EFL is the tree for the 1.7.x version of the libraries, and it will end > > when the version 1.7.2 will be released. e-0.17 will depend on 1.7.2, so I > > think they'll be released together on 21 december. > > actuy no - IN-EFL is simply historical reference of the trees as they were just > prior to merge into efl. this helps vincent and everyone fix up efl tree > problems quickly as we have an instant reference to the "last working state in > trunk". the 1.7.x (1.7.2) is a totally separate branch based on the 1.7.0 > release with JUSt bugfixes (no new features). the IN-EFL trees are actual > "development" trees with lots of additions and changes as well. :) > > > the various libraries in svn are being merged, one after the other, in a > > unified package, which is /efl. the last merged library is ecore. there will > > never be an ecore package in svn anymore, and the same will happen for efreet > > (and maybe for elementary too). we'll just have an efl.pot to translate :) > > correct. except for now elementary won't go in. we have some.. technical > problems to solve first. e_dbus won't go in either. edbus will, as will eio, > edje, and efreet. eeze probably needs to be there too. i'd like to see emotion > go in too. > > ethumb, e_dbus and elm are issues. e_dbus because its being superseded by > edbus and so we need to migrate to it (but e_dbus will never be killed until we > do efl 2.0 - it just will be separate). ethumb depends on e_dbus and needs to > migrate to edbus to be able to go in. elm also depends on e_dbus and ethumb. in > addition we have some other wonderful fun bits like efl webkit (outside of efl) > - it depends on efl, but not elm. but elm depends on webkit (optional) so we > have a circular dep here. for now the best thing to do is keep elm out until we > have a clear and clean solution to this. > as far as i remember correctly all efl libs/programs depend on edbus except for e17. barbieri changed them recently. > the only other thing - evas_generic_loaders. i'd like this to be in, but since > it was separated for license as well a stability reasons, i'm currently on the > fence as to if it can be put in without there being a license issue. > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ra...@ra... > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Enlightenment-intl mailing list > Enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-intl |
From: Carsten H. (T. R. <ra...@ra...> - 2012-12-05 05:32:37
|
On Wed, 5 Dec 2012 13:34:55 +0900 Daniel Juyung Seo <seo...@gm...> said: > > correct. except for now elementary won't go in. we have some.. technical > > problems to solve first. e_dbus won't go in either. edbus will, as will > eio, > > edje, and efreet. eeze probably needs to be there too. i'd like to see > emotion > > go in too. > > > > ethumb, e_dbus and elm are issues. e_dbus because its being superseded by > > edbus and so we need to migrate to it (but e_dbus will never be killed > until we > > do efl 2.0 - it just will be separate). ethumb depends on e_dbus and > needs to > > migrate to edbus to be able to go in. elm also depends on e_dbus and > ethumb. in > > addition we have some other wonderful fun bits like efl webkit (outside > of efl) > > - it depends on efl, but not elm. but elm depends on webkit (optional) so > we > > have a circular dep here. for now the best thing to do is keep elm out > until we > > have a clear and clean solution to this. > > > > as far as i remember correctly all efl libs/programs depend on edbus except > for e17. > barbieri changed them recently. orly? :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Aníbal <kh...@gm...> - 2012-12-05 20:59:54
|
I take a look at the launchpad page, and I see that it doesn't display correctly the stringstranslated, eg. any strings translated into Galician, this can lead to confusion, no? En 29/11/12 13:40, Massimo Maiurana escribiu: > Sérgio Marques, il 29/11/2012 11:08, ha scritto: >> I would prefer not having Portuguese translation at launchpad. Launchpad is >> well known for adventurers translating this and that just because they want. > your files are always updated, usually there nothing to translate in them so I > guess that nobody will pick them from launchpad ;) > |
From: Massimo M. <mai...@gm...> - 2012-12-05 21:35:45
Attachments:
signature.asc
|
Aníbal, il 05/12/2012 21:59, ha scritto: > I take a look at the launchpad page, and I see that it doesn't display > correctly the stringstranslated, eg. any strings translated into > Galician, this can lead to confusion, no? indeed it can. also, the translation page shows a situation that doesn't reflect the current svn, so if someone goes to e.g. https://translations.launchpad.net/enlightenment/trunk/+lang/it he surely thinks that there are a lot of strings to translate to italian, and it is of course a false assumption. -- Massimo Maiurana GPG keyID #7044D601 La fede e' credere in cio' che sai non essere vero [Mark Twain] |