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.

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.

Paul said:

Normally if we did overlook something we see somepone do it through the API

I'd disagree... The poor average Joe Translator just "does it somehow"... often just by typing it manually or similar crazy way... We see them here in the forum doing such things way too often even with standard formats :-\
People in general are weird, they won't look for systematic way, they won't look for repeatable and least-effort-needed way, they will "just do it somehow", again and again and again...

Paul said:

we have plenty of help around to deliver it in case the "average Joe" takes on a project like this

Thing is that to look for help you have to know that you don't know... but when you DON'T KNOW that you don't know, then you - logically - won't ask...
So in the end you get help (or simply information) just purely incidentally, when someone knowledgeable spots and correctly identifies the actual root cause of the issue... much like in this case.

Paul said:

It would be interesting to know if the tweaks people make are always the same

I'm pretty sure that - if anyone is knowledgeable enough to do the tweaks at all! - yes, the core of the tweaks simply MUST be the same (adding file extensions and their root elements, plus probably some additional element definitions like the keywords) by their nature.

Paul said:

make sure that you know what is required for translation out of the files you have

Heh, that's often a pure sci-fi... because the clients sending the files don't have the faintest idea :-(
Simply because they don't have the faintest idea about such stuff related to their job... because the nowadays' damned marketing liars brainwash the users to really believe that everything is "just a few clicks" and that they don't need to know anything... So majority of the people responsible for technical tasks like localization management know about computers and Internet just about that "it's that Facebook, Twitter and Instagram, right?"...... :-(

Paul said:

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

That's also rather sci-fi... because MadCap Flare projects usually consist of hundreds or even thousands of fgiles... so checking just some files is not enough since you easily miss those few files using some specialities like conditional or non-translatable content... and checking all files is not feasible.

You've got an answer for everything Evzen... but not very pragmatic.  It's a shame there aren't more of you to help make sure everyone does everything just right all of the time.

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.

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.

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.