El 2020-05-10 14:51, Samuel Sloniker escribió:
Would it be worth designing a parsing library?
On Sun, May 10, 2020 at 3:15 AM Flammie A Pirinen
wrote:
On Fri, May 08, 2020 at 04:50:45PM +0200, Tino Didriksen wrote:
For khannatanmai's GSoC project, secondary tags will be
implemented in a
Would it be worth designing a parsing library?
On Sun, May 10, 2020 at 3:15 AM Flammie A Pirinen wrote:
> On Fri, May 08, 2020 at 04:50:45PM +0200, Tino Didriksen wrote:
> > For khannatanmai's GSoC project, secondary tags will be implemented in a
> > backwards compatible manner. That it in
On Fri, May 08, 2020 at 04:50:45PM +0200, Tino Didriksen wrote:
> For khannatanmai's GSoC project, secondary tags will be implemented in a
> backwards compatible manner. That it in itself indisputable. But, there is
> a question of how the initial batch of secondary tags should look.
>
> I feel
On Sun, May 10, 2020 at 6:15 AM Flammie A Pirinen wrote:
>
> I don't personally find apertium stream format readable, if I need to
> make sense of it I will anyways have to preprocess a lot, enough that
> I'd say apertium stream format need visualisation scripts to be
> readable. It's not very
First of all, just to mention I don't consider myself a language developer
(but someone who messes around everything).
- I think I would leave this for the "secondary tag" developer, similar to
what we already do to the "primary tags" one. For example, no-one forbids
currently having a primary
