Alexander Lichanow said:

The file type is HTML 5, so I cannot leverage XPath for this.

That's incorrect. MadCap Flare files are XMLs, not HTMLs.
The simple fact that they contain custom non-HTML elements defined in the "MadCap" namespace (like the "MadCap:keyword" you mention) makes them XML, not HTML.

So your filetype should be defined as XML... and then you have the full power of XPath at your hands to define all elements you want.
For example, I was even able to define differently colored MadCap's tracked changes, similarly as MS Word (red striked-through for deletions, blue for additions)...

The files containing the keywords are all *.htm and have definitely been imported using the HTML 5 file type settings.

The other files (only *.flsnp in this specific projects) were imported as per MadCap XML settings, but those do not contain any keywords anyway.

Alexander Lichanow said:

The files containing the keywords are all *.htm and have definitely been imported using the HTML 5 file type settings.

File extension is irrelevant. File content is the only relevant thing. And the content clearly says it's XML.
So it's on you to configure Studio to use the appropriate file type to parse the files - e.g. to turn off the unwanted ones, or to move the wanted ones to the top of the list.

Unfortunately, the default Studio settings for MadCap files are completely wrong and incomplete :( and it takes some effort and knowledge to make it work as it should.

Later today when I get to a machine with Studio, I can post some screenshots of a correct and working setup.

I see that the "Related" column finally served a good purpose...
Here is my older thread with my customized filetype attached: community.sdl.com/.../customized-madcap-flare-file-type-disappears-from-project-settings-after-closing-and-reopening-studio

Well, this was my first Flare job so far and I was shocked to see that the MadCap XML file type settings do not even contain the basic Flare file types, such as *.flsnp. I managed to sort that out quickly, with the keywords remaining my only pain point at this stage.

Great, thanks, I'll wait for your reply then. I am also not in a hurry since I resorted to translating the keywords directly in EmEditor so I could deliver the files to my client. I'll just need the correct settings for the follow-up jobs they announced.

Well, this was my first Flare job so far and I was shocked to see that the MadCap XML file type settings do not even contain the basic Flare file types, such as *.flsnp. I managed to sort that out quickly, with the keywords remaining my only pain point at this stage.

Great, thanks, I'll wait for your reply then. I am also not in a hurry since I resorted to translating the keywords directly in EmEditor so I could deliver the files to my client. I'll just need the correct settings for the follow-up jobs they announced.

Alexander Lichanow said:

I was shocked to see that the MadCap XML file type settings do not even contain the basic Flare file types, such as *.flsnp.

Exactly.
Given that the file type was originally available only as separate download, it seems to me that the file type was born as some quick'n'dirty solution for some internal need... but that need was probably only for the HTML-like content translation, so they did not made the file type complete... and did not bother to complete it yet.

Evzen Polenka

I don't think it was quick and dirty... but I do recall discussing this around 2014 when I was looking at these (not sure if these are a complete list or not, or whether they all contain translatable content or not):

.htm/.html: Topic file

.flglo: Glossary file

.fltar: Target file

.fltoc: Table of contents file

.flvar: Variable set file

.flsnp: Snippet file

.flsfs: Search filter set file

*.flmsp: Flare template master page file

*flpgl: Flare template page layout file

I think the response at the time was that without a proper spec for them and engaging with MadCap the developer was reluctant to base changes on the few examples we ever came across.  I'll see what the current thoughts are on this as the filetype hasn't evolved since it was put into Studio 2015 as part of the product.  It's still XML: MadCap 1.2 v 1.0.0.0.

Paul said:

without a proper spec for them and engaging with MadCap the developer was reluctant to base changes on the few examples we ever came across.

To be honest, I would expect that a company claiming to be an industry leader WILL get in touch with MadCap when developing an official connector.
Or at least invest a half-day or a day in some basic own research (e.g. it's not that problematic to get MadCap installed, read the documentation, do some Googling, etc.)... Still better than nothing if no official spec is available.

Since it looks like that this did not happen (as not even the basic file extensions you just listed are included in the filetype definition), it naturally led to me to a conclusion that it was just some quick'n'dirty guerilla action...

Regarding basing changes on just a few examples - I would think that this is what e.g. the beta forum (or the forums in general and closer personal relations with users) are for. It's easy to get connected with users of that particular functionality and improve it together... as long as the users' ideas and tips actually get implemented in a sensible time frame, of course.

You're right Evzen Polenka... it's so easy I don't know why we didn't do it.  Perhaps because these other formats don't come up a lot... I hardly ever see them and the last mention I had was many years ago.  It's also simple to solve so no real urgency either.

I have asked the question though so perhaps we'll find out shortly.

Those file type settings worked perfectly, thank you very much!

Evzen Polenka

I did have a discussion with the developer this morning on this and the reason is as I thought... we never see a demand for these so the filetype was created to support the demand.  So far it's fairly trivial to handle the others with the tools provided when you need to do it.

I know it would be desirable for completeness, but when you have a lot on your plate the return on the investment of your time is sometimes not worth it compared to other things that really are needed.

Well ;-)... it's fairly trivial as long as you know what to do and how to do it... which is not the case of "average Joe Translator".

While I understand and respect the business reasons (we are, just as many other companies, in the same situation), it's precisely what drives me mad - how is one then supposed to answer the client's questions "why this doesn't work? why that is not completed? why module A doesn't do it when module B does it?"...
Come on, product managers who made the decisions, answer these questions! You made the decision, so YOU stand in front of the potential buyers and tell them yours "nah, it wasn't worth it for us"... :-\

That's why I always strongly push for (reasonable) completeness right from the beginning... because I don't believe in iterative improvements... that usually never happens... there's always something "more important".

Blah... ;-)

Well, being the Average Joe who will mostly receive pre-made packages or at least reasonable Office formats, I was a bit lost when I received a huge package of Flare files from this client. To be honest, I hadn't even heard of this tool before. So then I quickly found out that there is a MadCap XML standard filter in Studio 2017, which is pretty much worthless without user-defined tweaks - but to do those tweaks, one needs to know more about the format than Mr. A. Joe ;)

Evzen Polenka said:

That's why I always strongly push for (reasonable) completeness right from the beginning... because I don't believe in iterative improvements... that usually never happens... there's always something "more important".

I'd agree with you Evzen... in a very simplistic world.  Sadly we don't live in that world and it's not always possible when you have many competing objectives.  So all the teams do the best they can, with the resources they have, and the time they have available.  If we see this requirement come up half a dozen times in many years then I think they probably made the right choice.

Normally if we did overlook something we see somepone do it through the API... not just in the appstore but also in the hundreds of plugins we sign on a regular basis.  We do see many filetypes... but I can tell you we have never seen one for this.

This time I think a certain amount of technical knowledge can be expected and we have plenty of help around to deliver it in case the "average Joe" takes on a project like this.  In this case, thanks to you, the issue is also solved.

Alexander Lichanow said:

which is pretty much worthless without user-defined tweaks - but to do those tweaks, one needs to know more about the format than Mr. A. Joe ;)

It would be interesting to know if the tweaks people make are always the same, and then we have a good case for adapting the filetype defaults.

I'd also make sure that you know what is required for translation out of the files you have.  That is the most important thing when handling any XML and if the client didn't tell you, or you didn't ask, then even with the tweaks from Evzen you are going into this blindly.  I don't believe all requirements are the same as it can depend on how the client is using the authoring tool in the first place.

It's worth pseudotranslating (use dollar symbols) some of the files as a check and look to see whether or not you are missing anything, and also if you have done too much.