13 iyn 2020, Ş. tarixində 13:15 tarixində <nlhow...@gmail.com> yazdı:
>
> Tino Didriksen wrote:
> > On Sat, 13 Jun 2020 at 17:50, Francis Tyers <fty...@prompsit.com> wrote:
> >
> > > As far as I understand the objective is to be able
> > > to
> > > put the original surface form in the output translation as an unknown
> > > token
> > > instead of the lemma.
> > >
> > > ...
> > >
> > > I think that the appropriate way to deal with this is by coming up with
> > > a
> > > clear plan for the linguistic eventualities. I don't see that in the
> > > current
> > > proposal. I have been showing Tanmai through the creation of a new MT
> > > system,
> > > and we have been documenting these issues as they arise. I don't think
> > > it makes
> > > sense to start development before they have been resolved.
> > >
> >
> >
> > Those are important issues, but they're orthogonal to how to transport
> > secondary information through the pipe.
>
> > Even at the earliest stages of the proposal, it was expanded to be
> > 1) Get secondary tags through the pipe. 2) Use that ability to
> > eliminate trimming. 3) Use the same ability for a myriad of other
> > things, such as markup handling.
>
> If I understand the issue correctly, it isn't clear yet that (2) as
> phrased is possible.
>
> *Is there* an answer yet to what we *want* to happen in
>
> > such as what should happen to secondary information when tokens are
> > merged/split.
>
> ?

I agree.  A proposed solution to the issues Fran raises need to be
part of the proposal for transport format.  The issues are too closely
intertwined.

> Not about the algorithm or implementation or anything. Just, what
> would we like the result to be?
>
> > We need to implement and solve #1 first - be able to transport (and
> > potentially manipulate) any amount of data that might be needed to
> > solve #2 and #3 and ... #9.
>
> I don't think it makes sense to mandate a mechanism we aren't
> convinced will work...

This has never been suggested as a mandate.  Whatever the approach to
the issues at hand, the proposal is for an extra feature that
translation pair developers may decide to use or ignore as they see
fit.

I want to also highlight Tino's point about urgency.  This is part of
an active GSoC project, and that project needs to move forward.  That
doesn't mean that this discussion shouldn't be allowed to take its
time, but we really do need to find a path forward.

--
Jonathan


> Cheers,
> Nick


_______________________________________________
Apertium-stuff mailing list
Apertium-stuff@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/apertium-stuff

Reply via email to