framework for translating our webpage
Ondřej Čertík
I have spent several hours and did research how to translate and
maintain our webpages. Let's use the .po and .pot files (the unix
gettext utility, together with Python's gettext, Babel package and a
support for it in Jinja2). I have described it in the pull request:
https://github.com/sympy/sympy.github.com/pull/33
It has been a lot of work to prepare this and figure out how to make
jinja2 work and finally to make *all* strings in the templates
translatable. However, this is now done and it's running at sympy.org.
Read the pull request for more technical details.
As an example, here is the .po file for the Czech translation:
https://github.com/sympy/sympy.github.com/blob/master/i18n/cs.po
I have manually copied the translation from the pull request:
https://github.com/sympy/sympy.github.com/pull/30, and that's quite
time consuming.
If you all agree, let's ask students to submit the .po file directly,
by adapting the template here:
https://github.com/sympy/sympy.github.com/blob/master/i18n/sympy.org.pot
This framework also fixes the issue of synchronization. When making
any change in the English pages, three cases can occur:
1) the change doesn't touch any translatable string. Then the change
will happen in all translated pages without any effort.
2) the change changes some translatable string, but it happen to use
some other string, that is already translated in the .po file. Then
the translation will automatically work without any effort.
3) the change changes some translatable string into a new string for
which the translation is not available yet. Then the .po file has to
be regenerated by merging with the new template (by using the msgmerge
utility in linux), and by default it will have no translation for the
new string. As such, an English translation will be used instead until
the string is translated in the po file.
As you can see, only the case 3) causes problems, and even then things
will be synchronized, just not completely 100% translated. And we can
use standard tools that handle the .po and .pot files to manage
translations.
As far as the tutorial goes, something similar should probably be
done, but I don't have time for it, so I suggest to simply have the
tutorial in several languages as an html file, but for the webpages,
that we need to modify quite often, I think it is very important to
use some framework like above, so that we can make sure that it is
updated in all languages.
So I think that this framework fixes all the problems, and let me know
what you think of it and if you agree, let's use it and improve upon
it. Most importantly, create new GCI tasks (?) to convert the already
done translation pull requests into a .po file, and convert all tasks
that weren't yet done to simply submit a .po file.
Ondrej
Ondřej Čertík
>
> https://github.com/sympy/sympy.github.com/blob/master/i18n/cs.po
>
> I have manually copied the translation from the pull request:
> https://github.com/sympy/sympy.github.com/pull/30, and that's quite
> time consuming.
I forgot to mention that I only copied a few parts, as I don't have
time to copy the rest.
Ondrej
Vladimir Perić
still created a "Research" task for GCI to see if something better
could be found. I didn't look at the exact changes you made, but I
guess any problems will get noticed sooner rather than later. We
should probably do the same for the tutorial (in the long run, I
wouldn't mess around with it for GCI), if we do agree that we want to
keep translating documentation (though, again, I don't really see the
value in that).
2011/11/27 Ondřej Čertík <ondrej...@gmail.com>:
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>
>
--
Vladimir Perić
Ondřej Čertík
> Yeah. I always thought .po files would be the way to go, though I
> still created a "Research" task for GCI to see if something better
> could be found. I didn't look at the exact changes you made, but I
> guess any problems will get noticed sooner rather than later. We
> should probably do the same for the tutorial (in the long run, I
> wouldn't mess around with it for GCI), if we do agree that we want to
> keep translating documentation (though, again, I don't really see the
> value in that).
I would keep the tutorial as a regular page, to keep things simple on everybody.
But for the webpages, we need something more robust, so that we can
change things easily. Unfortunately, I noticed, that the Czech,
German, Polish and Bulgarian translations are already done
(https://github.com/sympy/sympy.github.com/pulls), so we'll have to
create new issues/tasks to convert the pull request into a .po file.
Ondrej
Vladimir Perić
> On Sun, Nov 27, 2011 at 1:10 PM, Vladimir Perić <vlada...@gmail.com> wrote:
>> Yeah. I always thought .po files would be the way to go, though I
>> still created a "Research" task for GCI to see if something better
>> could be found. I didn't look at the exact changes you made, but I
>> guess any problems will get noticed sooner rather than later. We
>> should probably do the same for the tutorial (in the long run, I
>> wouldn't mess around with it for GCI), if we do agree that we want to
>> keep translating documentation (though, again, I don't really see the
>> value in that).
>
> I would keep the tutorial as a regular page, to keep things simple on everybody.
So what happens when we update the tutorial? Or notice a mistake
somewhere and correct it? How will we know if (and what parts) are out
of date. I dunno, like I said, I still think the whole thing is too
much hassle for too little gain. Still... :)
>
> But for the webpages, we need something more robust, so that we can
> change things easily. Unfortunately, I noticed, that the Czech,
> German, Polish and Bulgarian translations are already done
> (https://github.com/sympy/sympy.github.com/pulls), so we'll have to
> create new issues/tasks to convert the pull request into a .po file.
>
> Ondrej
>
Ondřej Čertík
On Sun, Nov 27, 2011 at 1:31 PM, Vladimir Perić <vlada...@gmail.com> wrote:
> 2011/11/27 Ondřej Čertík <ondrej...@gmail.com>:
>> On Sun, Nov 27, 2011 at 1:10 PM, Vladimir Perić <vlada...@gmail.com> wrote:
>>> Yeah. I always thought .po files would be the way to go, though I
>>> still created a "Research" task for GCI to see if something better
>>> could be found. I didn't look at the exact changes you made, but I
>>> guess any problems will get noticed sooner rather than later. We
>>> should probably do the same for the tutorial (in the long run, I
>>> wouldn't mess around with it for GCI), if we do agree that we want to
>>> keep translating documentation (though, again, I don't really see the
>>> value in that).
>>
>> I would keep the tutorial as a regular page, to keep things simple on everybody.
>
> So what happens when we update the tutorial? Or notice a mistake
> somewhere and correct it? How will we know if (and what parts) are out
> of date. I dunno, like I said, I still think the whole thing is too
> much hassle for too little gain. Still... :)
Those are valid questions, however, I think that the right question to
ask is the following:
* given that we already have translations of the tutorial and given
our manpower, what is the best way for us to use it?
And my own answer is (given how often we will update the tutorial):
* Just add a hash of the English original into each tutorial and add
it into our documentation.
Then if we improve the English tutorial, the translations will be out
of date, but they will have a hash/link for more up-to-date English
translation.
Ondrej
Joachim Durchholz
> Yeah. I always thought .po files would be the way to go,
Me too. I do not think anything better is even possible; not if the goal
is "the minimum amount of maintenance burden that allows us to have a
reasonable solution".
There are powerful translation workbenches, but my understanding is that
they are built for teams of full-time translators, which we are not.
(Among the things such a workbench typically requires is that you build
an as complete as possible domain-specific terminology, then it will
automatically do 80% of the translation work for you - but setting up
that terminology is so much work that we'd end up doing more work, and
you'd need to be specifically trained to even work on the terminology.)
> guess any problems will get noticed sooner rather than later. We
> should probably do the same for the tutorial (in the long run, I
> wouldn't mess around with it for GCI),
I agree with that.
We can put the translations into the gettext infrastructure after the fact.
> if we do agree that we want to
> keep translating documentation (though, again, I don't really see the
> value in that).
It depends on the target audience.
Math&physics researchers should know English already, it's their lingua
franca anyway.
Highschool students can have a better grasp of mathematics than English;
if we wish to serve these, translations would help.
Engineers... it depends. Some countries expect their engineers to learn
English as a matter of course, others don't. E.g. I would expect French
universities to discourage people to doing too much in English.
Regards,
Jo
Ondřej Čertík
>> should probably do the same for the tutorial (in the long run, I
>> wouldn't mess around with it for GCI),
>
> I agree with that.
> We can put the translations into the gettext infrastructure after the fact.
I have updated tasks that are not done yet with a specific requirement
to submit the .po files.
I am now trying to convert the Czech translation to a .po file and it
is a lot of work, so I think it's much better if the translation
itself is in a .po file.
Ondrej
Joachim Durchholz
> I am now trying to convert the Czech translation to a .po file and it
> is a lot of work, so I think it's much better if the translation
> itself is in a .po file.
Hmm... the gettext toolchain is prepared to write your own text
extractors. (Those for C source code look for _("..."), for example.)
If there's a gettext extractor for the markup used in the tutorial, it
should be able to automatically extract a skeleton from the English
originals.
I think an extractor is the first thing you need to reasonably work with
gettext. Creating .po files manually is possible, but you'd have to keep
them in sync with the markup text manually, which makes the whole effort
of using gettext pointless.
BTW you do not need a hash. The gettext tools will simply check whether
.po and source are in sync.
Regards,
Jo
Vladimir Perić
> Am 27.11.2011 22:50, schrieb Ondřej Čertík:
>>
>> I am now trying to convert the Czech translation to a .po file and it
>> is a lot of work, so I think it's much better if the translation
>> itself is in a .po file.
>
> Hmm... the gettext toolchain is prepared to write your own text extractors.
> (Those for C source code look for _("..."), for example.)
The Python one works the same, I know GRAMPS uses it (but I've no
experience with it exactly, I've just translated some things).
>
> If there's a gettext extractor for the markup used in the tutorial, it
> should be able to automatically extract a skeleton from the English
> originals.
> I think an extractor is the first thing you need to reasonably work with
> gettext. Creating .po files manually is possible, but you'd have to keep
> them in sync with the markup text manually, which makes the whole effort of
> using gettext pointless.
>
> BTW you do not need a hash. The gettext tools will simply check whether .po
> and source are in sync.
Yeah, if we do decide to do anything with these, I'm absolutely
positive we should go for gettext integration as it's a very robust
system and there's really no reason not to. For the moment, though, I
of course agree with Ondřej - as long as we have the texts we should
definitely use them. Lets just add a date-stamp to each file and be
done with "versioning" them.
Still, I'd like to make a case again for *not* doing any translating:
SymPy is, at it's core, a program that's aimed at academia and people
with at least some sort of math background. Most of these will have
good knowledge of English, both mathematicians and physics and
engineers. Yes, I know how much Czech (French, whoever) people like
their language, but the fact is that English is the language of
programming, hence also the language of Python and therefore the
language of SymPy. Whatever we do our methods are always going to be
called "solve", "transpose" or whatever, and they'll never use
translated names. Therefore SymPy will never be usable by someone who
has no knowledge of English and trying to keep translated
documentation is going to be tedious at best and plain pointless at
worst.
On the other hand, I of course recognize the importance of
translation, as we do live in an international word after all. So I
support completely all efforts to translate the webpage, or our
interface if we had one (well, SymPy Live can be considered an UI), I
just don't think it's worthwhile for us to translate our documentation
or bother at it at all. Aaron himself said the only reason he added
translation tasks is because Google required it.
But hey, that's just my view.
>
> Regards,
> Jo
Ondřej Čertík
> Am 27.11.2011 22:50, schrieb Ondřej Čertík:
>>
>> I am now trying to convert the Czech translation to a .po file and it
>> is a lot of work, so I think it's much better if the translation
>> itself is in a .po file.
>
> Hmm... the gettext toolchain is prepared to write your own text extractors.
> (Those for C source code look for _("..."), for example.)
>
> If there's a gettext extractor for the markup used in the tutorial, it
> should be able to automatically extract a skeleton from the English
> originals.
> I think an extractor is the first thing you need to reasonably work with
> gettext. Creating .po files manually is possible, but you'd have to keep
> them in sync with the markup text manually, which makes the whole effort of
> using gettext pointless.
This is already done, see my pull request. We have the English
template (see my pull request), but
we need to fill it in, manually, using the Czech translation, that was
done in the html files directly.
Anyway, I have now finished this as well, it took me about 1h of work.
Here is the result:
http://sympy.org/cs/index.html
>
> BTW you do not need a hash. The gettext tools will simply check whether .po
> and source are in sync.
The tutorials do not use gettext, so we need a hash (I think).
Ondrej
Ondřej Čertík
> On Sun, Nov 27, 2011 at 11:04 PM, Joachim Durchholz <j...@durchholz.org> wrote:
>> Am 27.11.2011 22:50, schrieb Ondřej Čertík:
>>>
>>> I am now trying to convert the Czech translation to a .po file and it
>>> is a lot of work, so I think it's much better if the translation
>>> itself is in a .po file.
>>
>> Hmm... the gettext toolchain is prepared to write your own text extractors.
>> (Those for C source code look for _("..."), for example.)
>
> The Python one works the same, I know GRAMPS uses it (but I've no
> experience with it exactly, I've just translated some things).
It was tricky to get this working with jinja, as the documentation is
scarce. It took me about 4h of work in the morning, but it's done (see
my pull request).
>
>>
>> If there's a gettext extractor for the markup used in the tutorial, it
>> should be able to automatically extract a skeleton from the English
>> originals.
>> I think an extractor is the first thing you need to reasonably work with
>> gettext. Creating .po files manually is possible, but you'd have to keep
>> them in sync with the markup text manually, which makes the whole effort of
>> using gettext pointless.
>>
>> BTW you do not need a hash. The gettext tools will simply check whether .po
>> and source are in sync.
>
> Yeah, if we do decide to do anything with these, I'm absolutely
> positive we should go for gettext integration as it's a very robust
> system and there's really no reason not to. For the moment, though, I
> of course agree with Ondřej - as long as we have the texts we should
> definitely use them. Lets just add a date-stamp to each file and be
> done with "versioning" them.
+1
>
> Still, I'd like to make a case again for *not* doing any translating:
> SymPy is, at it's core, a program that's aimed at academia and people
> with at least some sort of math background. Most of these will have
> good knowledge of English, both mathematicians and physics and
> engineers. Yes, I know how much Czech (French, whoever) people like
> their language, but the fact is that English is the language of
> programming, hence also the language of Python and therefore the
> language of SymPy. Whatever we do our methods are always going to be
> called "solve", "transpose" or whatever, and they'll never use
> translated names. Therefore SymPy will never be usable by someone who
> has no knowledge of English and trying to keep translated
> documentation is going to be tedious at best and plain pointless at
> worst.
>
> On the other hand, I of course recognize the importance of
> translation, as we do live in an international word after all. So I
> support completely all efforts to translate the webpage, or our
> interface if we had one (well, SymPy Live can be considered an UI), I
> just don't think it's worthwhile for us to translate our documentation
> or bother at it at all. Aaron himself said the only reason he added
> translation tasks is because Google required it.
I think it's worthy to translate the webpage, and maybe the tutorial.
I don't think it's worthy to translate everything else, given our
current manpower.
Since we are translating the webpage and the tutorial (and nothing
else), I don't see any problem here.
Ondrej
Ronan Lamy
I don't think we need to do version control manually, we should just use
the git history for that.
>
> Still, I'd like to make a case again for *not* doing any translating:
> SymPy is, at it's core, a program that's aimed at academia and people
> with at least some sort of math background. Most of these will have
> good knowledge of English, both mathematicians and physics and
> engineers. Yes, I know how much Czech (French, whoever) people like
> their language, but the fact is that English is the language of
> programming, hence also the language of Python and therefore the
> language of SymPy. Whatever we do our methods are always going to be
> called "solve", "transpose" or whatever, and they'll never use
> translated names. Therefore SymPy will never be usable by someone who
> has no knowledge of English and trying to keep translated
> documentation is going to be tedious at best and plain pointless at
> worst.
>
> On the other hand, I of course recognize the importance of
> translation, as we do live in an international word after all. So I
> support completely all efforts to translate the webpage, or our
> interface if we had one (well, SymPy Live can be considered an UI), I
> just don't think it's worthwhile for us to translate our documentation
> or bother at it at all. Aaron himself said the only reason he added
> translation tasks is because Google required it.
>
> But hey, that's just my view.
Language competence isn't a binary thing. I'm sure that a large majority
of French Python programmers can understand a typical docstring, but
most of them are probably not comfortable reading a long text in
English. Having a tutorial in French can give them an easy entry point,
allowing them to decide whether it's worth their time to make the effort
of understanding the rest of the docs.
Joachim Durchholz
> On Sun, Nov 27, 2011 at 2:04 PM, Joachim Durchholz<j...@durchholz.org> wrote:
>> I think an extractor is the first thing you need to reasonably work with
>> gettext. Creating .po files manually is possible, but you'd have to keep
>> them in sync with the markup text manually, which makes the whole effort of
>> using gettext pointless.
>
> This is already done, see my pull request.
Ah ok, I got from your message that is was the .po you were creating
manually.
> We have the English
> template (see my pull request), but
> we need to fill it in, manually, using the Czech translation, that was
> done in the html files directly.
>
> Anyway, I have now finished this as well, it took me about 1h of work.
Well, that's acceptable :-)
>> BTW you do not need a hash. The gettext tools will simply check whether .po
>> and source are in sync.
>
> The tutorials do not use gettext, so we need a hash (I think).
Ah, I understand.
My suggestion would be to integrate the tutorials into the gettext
infrastructure. Because we want to do that anyway (to make identifying
translation-relevant changes less work), and we can spare the work of
setting up a mechanism to monitor hash changes.
Regards,
Jo
Aaron Meurer
document is, and who can translate it/verify the translation. Right
now, we have exactly one person per language (except I guess we have
two for Czech), so our ability to verify translations, much less make
them is very limited. If we tried to do it outside of Code-In, we
would have to drop the review requirement, as there's simply no one
else to verify it, which makes me a little uneasy about it. As was
mentioned earlier, it's better to have no translation than a poor
translation, and while I'm not saying that anybody is poor at
translating, the fact is, with no quality assurance, we simply don't
know how good it is.
But I agree that some things, like the webpage or Wikipedia articles,
are very good to translate for outreach purposes.
So Ondrej, with your work, is
http://www.google-melange.com/gci/task/view/google/gci2011/7127301
still relevant? If so, can you update it with what still needs to be
done? Otherwise, let's close it.
Aaron Meurer
> Language competence isn't a binary thing. I'm sure that a large majority
> of French Python programmers can understand a typical docstring, but
> most of them are probably not comfortable reading a long text in
> English. Having a tutorial in French can give them an easy entry point,
> allowing them to decide whether it's worth their time to make the effort
> of understanding the rest of the docs.
>
>
Ondřej Čertík
> I agree with this. We have to consider many factors, like what the
I also agree with Ronan.
> document is, and who can translate it/verify the translation. Right
> now, we have exactly one person per language (except I guess we have
> two for Czech), so our ability to verify translations, much less make
> them is very limited. If we tried to do it outside of Code-In, we
> would have to drop the review requirement, as there's simply no one
> else to verify it, which makes me a little uneasy about it. As was
> mentioned earlier, it's better to have no translation than a poor
> translation, and while I'm not saying that anybody is poor at
> translating, the fact is, with no quality assurance, we simply don't
> know how good it is.
We should only translate things, that we can verify to make sure that
the language looks good and also
that the burden on us is acceptable.
I wasn't aware of the gettext framework much, until I spent a lot of
time with it yesterday and I must say, that it's actually very nice
and manageable. For example, you can use the "poedit"
(http://www.poedit.net/) program to edit/translate the po files and so
on.
>
> But I agree that some things, like the webpage or Wikipedia articles,
> are very good to translate for outreach purposes.
>
> So Ondrej, with your work, is
> http://www.google-melange.com/gci/task/view/google/gci2011/7127301
> still relevant? If so, can you update it with what still needs to be
> done? Otherwise, let's close it.
In fact, I have already updated the issue with the task description,
which is this one:
http://code.google.com/p/sympy/issues/detail?id=2795
suggesting to implement the gettext framework for Sphinx, as Jo
independently also suggested above. It's invigorating that I
independently either implemented or suggested the same things as Jo,
so I think there is good agreement on using gettext.
Ondrej
Aaron Meurer
Great. Let's do it then. Don't feel like you have to not fix it to
leave it for some student because it's a GCI task. If it will make
life easier to just fix it yourself, please do so.
Aaron Meurer
Ondřej Čertík
We should fix it ourselves, so that it's done and in sympy before
December 16 for the second round of tasks.
However, I don't have time for it. Yesterday I spent all day with the
webpages, it was a lot of work, but I think the framework is done at
least.
Ondrej
Aaron Meurer
thinking of adding tasks to translate the Wikipedia article, but
that's it. What other documents should we have translated?
Aaron Meurer
Ondřej Čertík
What I meant was to create gci tasks to convert the tutorial translations to use gettext.
Send from mobile phone
Ondřej Čertík
> What I meant was to create gci tasks to convert the tutorial translations to
> use gettext.
And the same for the webpage. Otherwise we'll have to do it yourselves,
it took my about 1h of solid work. So times 7 (or how many) translations,
for both webpage and tutorial, so that's a lot of work that somebody
will have to do. So if we make this the GCI task, it will save us tons
of time.
Ondrej
Aaron Meurer
this. I don't know much about gettext, so I didn't put much
information there. If you could add more, that would be great.
Also, I didn't know what difficulty to put (I just put medium for
now), and also what other categories it can go into (is it code?).
Aaron Meurer
2011/11/28 Ondřej Čertík <ondrej...@gmail.com>:
Ondřej Čertík
> I created http://code.google.com/p/sympy/issues/detail?id=2879 for
> this. I don't know much about gettext, so I didn't put much
> information there. If you could add more, that would be great.
>
> Also, I didn't know what difficulty to put (I just put medium for
> now), and also what other categories it can go into (is it code?).
I think so, it's code. I will try to do it, if I have time, we'll see.
This is one of the issues which are not clear how much work it is
going to be, because I don't know exactly how to integrate gettext
with sphinx. We'll have to experiment.
Ondrej
Aaron Meurer
In that case, we can also add the research tag :)
Aaron Meurer
Joachim Durchholz
> I agree with this. We have to consider many factors, like what the
> document is, and who can translate it/verify the translation. Right
> now, we have exactly one person per language (except I guess we have
> two for Czech), so our ability to verify translations, much less make
> them is very limited. If we tried to do it outside of Code-In, we
> would have to drop the review requirement, as there's simply no one
> else to verify it, which makes me a little uneasy about it. As was
> mentioned earlier, it's better to have no translation than a poor
> translation, and while I'm not saying that anybody is poor at
> translating, the fact is, with no quality assurance, we simply don't
> know how good it is.
In fact I wouldn't recommend doing a translation unless there is at
least a second volunteer for review. Partly because this improves the
quality significantly, and partly because there's the risk that the
translator drops out.
Joachim Durchholz
Joachim Durchholz
> I think so, it's code. I will try to do it, if I have time, we'll see.
> This is one of the issues which are not clear how much work it is
> going to be, because I don't know exactly how to integrate gettext
> with sphinx. We'll have to experiment.
Um... does http://sphinx.pocoo.org/latest/intl.html answer that question?
(It was the first Google result for sphinx gettext.)
Ondřej Čertík
I think that is exactly it! Somebody just has to submit a pull request
with implementing this in sympy docs.
Ondrej
Happy Nawani
krastano...@gmail.com
If any hindi task is there i can do it and in sindhi too I mean making text files as .po files please tell me and provide me the link at my mail id nawan...@gmail.complease
--
You received this message because you are subscribed to the Google Groups "sympy" group.
To view this discussion on the web visit https://groups.google.com/d/msg/sympy/-/lZgMhZKj98AJ.
Ondřej Čertík
(not as a part of GCI), that would be great.
We can then find somebody else speaking Hindi to check it and push it in.
Let us know.
Ondrej
Happy Nawani
tasks http://www.google-melange.com/gci/student_tasks/google/gci2011/
nawanihappy and completely trust on me.One of the mentors told me
that you can replace some tasks and he told me to ask for the hindi
translation in the group discussion so that everyone comes to know
about it that's why I did that .so couldyou please do me this favour
by replacing the task to which no one has responded till now.
> However, if you would like to contribute the Hindi translation anyway
> (not as a part of GCI), that would be great.
> We can then find somebody else speaking Hindi to check it and push it in.
>
> Let us know.
>
> Ondrej
>
>
>
>
>
>
>
> <krastanov.ste...@gmail.com> wrote:
> > I don't think that we have any mentors that can check such translations.
> > There are some developers that may be capable but I'm not sure whether they
> > participate as GCI mentors. And also it's impossible to add new task (the
> > deadline for additional tasks has passed). I'm sorry.
>
>
> >> If any hindi task is there i can do it and in sindhi too I mean making
> >> text files as .po files please tell me and provide me the link at my mail id
Ondřej Čertík
> hey sir u dont worry about the transltion you can see my
> tasks http://www.google-melange.com/gci/student_tasks/google/gci2011/
> nawanihappy and completely trust on me.One of the mentors told me
> that you can replace some tasks and he told me to ask for the hindi
> translation in the group discussion so that everyone comes to know
> about it that's why I did that .so couldyou please do me this favour
> by replacing the task to which no one has responded till now.
As Stefan already said, we cannot replace a task at GCI. Sorry about that.
Ondrej