Markdown segmentation

General Questions
1

Hey, just wondering what rule is using by Crowdin for .MD files segmentation. Can it be changed? I have some files that look not in the best way in editor, so changing might help me a lot. Thanks in advance.

2

Hi, it’s SRX 2.0. You can add some custom rules:

1 Like
3

@Dima Thanks. I just tried this for a markdown file. The rule I want to add is to create a split after an aside (tip, warning, note) using the vuepress format. That will then mean that if I change my asides later, at least only the string for the aside is changed - not the content:

     <!-- Split after :::warning or tip or note or info or caution -->
      <rule break="yes">
          <beforebreak>:::\s*?(warning|info|tip|caution|note)</beforebreak>
          <afterbreak>.*?</afterbreak>
      </rule>

My question though, is how do I apply this to the existing markdown set without modifying the existing default rules? All the segmentation rule examples assume you provide a whole rule file, but I’d prefer just “append” this rule because there might be others that I am missing (lots of unintended consequences).

If not, then I need to know the default rules so I can include the whole file - do you know what they are?

4

Hello @hamishwillee

I’ve spoken with developers, and theoretically, we might even be able to add such a rule to the list of supported rules.

However, our tech team has some concerns about the overall usage of this rule.

The thing is, we greatly support custom containers from vuepress with some spaces:

With a certain number of spaces between and types
::: some spaces warning|info|tip|caution|note

You still can add an enter between ::: and warning|info|tip|caution|note, but in this case vuepress will not be able to process it

5

Hi @Dima
Thanks - are you saying that this will break on the tip?

::: tip
body

Most of my asides are like this (no space) which works in Vuepress/Vitepress but in Crowdin the following sentence does not break.

:::tip
body

So the string ends up :::tip body (and of course there is the other issue that the trailing ::: in the output is appended at the end - swallowing the line break).

6

Thanks for the quick reply!

Let me double-check a few things from my side (just want to provide you with the best possible solution). I will return with an answer in some time :slight_smile:

7

Hi,

Checked everything, and right now we’re investigating the possibility of improvement on the system level. This should be fixed by system import/export, not the srx rules.

We have created an internal task (46125) because currently, depending on where containers exist, or when there are spaces inside, some custom containers can be parsed not as well as expected.

I’d suggest waiting some time for our investigation to finish and improvement to be released. Still, I can’t provide any ETA about this.

I send you a file with srx rule by email, you’re welcome to run some additional tests on your end. We strongly recommend using a test project instead of a production one.

8

Thanks @Dima

That sounds sensible - there will be cases where SRX makes sense, but this does sound like one where getting the system import/export right would be better.

Really appreciate your help. I have every faith in the Crowdin development team.
Never let me down.

Thank you.

1 Like