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.

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.

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 ;)

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 ;)

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.

Alexander Lichanow said:

I was a bit lost when I received a huge package of Flare files from this client

BTW, that just confirms what I wrote - that the people creating the jobs don't have the faintest idea... simply because Flare has the option to export XLIFF files instead of the original sources.

So again, if the client would know how to use their tool properly, you would not have any issue...

I worked on a few Flare projects and it was always the same - the clients providing the jobs simply didn't know what the tool is capable of.

Evzen Polenka said:

So again, if the client would know how to use their tool properly, you would not have any issue...

I worked on a few Flare projects and it was always the same - the clients providing the jobs simply didn't know what the tool is capable of.

To be fair Evzen, I think part of the job of the translator is to educate the client so they get what they need.  I think many companies starting to look at localization go into it with little knowledge and this is where their partner has a responsibility to provide that professionalism.  It may mean the company realises they need to employ a localization engineer... or it may mean they rely on their partner to tell them what they need.  But if neither side understand what's required then it is a recipe for disaster.

It's simply not enough to keep complaining about the lack of understanding... if we want to be recogninsed as professionals in this field we have the responsibility to educate the client and ourselves.

Call that sci-fi if you like, but there are enough ways to get educated today so there is really no excuse if you want to tackle work of this nature.

My client was knowledgeable enough about their tools to recommend that I use MadCap Lingo instead of Studio. It's just that I didn't exactly feel like spending 800 euros on a severely over-specialized tool which I will only ever need to translate one very specific (and somewhat esoteric) type of files. They also did admit to not knowing anything about SDL Studio and thus couldn't support me at all with any suggestions as to what I need to define in the parser and file type settings.

Paul said:

I think part of the job of the translator is to educate the client so they get what they need

Sure, that's what I strongly believe in as well. And believe me, I tried hard.

Unfortunately, vaste majority of my managers in the last few years had completely opposite opinion - they pushed for "we have to do ANYTHING for the client... whatever the client wants, we have to fulfill that", no matter how wrong the client's idea or requirement was.
Educate the client? No way! That would be like saying "you do it wrong", but client is always right...

And the clients? Well, again, majority of them simply didn't know what I'm talking about when I tried to educate them and explain that there are easier, more effective ways. And the others had no interest, they were told by their superiors to do things this way and that was it...

So it's no wonder that I say what I say... That's my real-life experience from the localization world.
It wasn't always like that. 20 years ago it was different... because there were still educated and willing-to-be-educated people in the industry.

Alexander Lichanow said:

My client was knowledgeable enough about their tools to recommend that I use MadCap Lingo instead of Studio.

I wouldn't call it "knowledgeable" really... It's not that difficult to know about Lingo if the default export function says "Export MadCap Lingo bundle" ;-)