Since we are on the topic:

One big issue with these custom import filters is, that if you create a package and the translator does not have the filter installed, he cannot translate it.

Having all our translators install special filters is not really a good solution.

Would be good if this would be optional....

The business aspect doesn't really bother me so much, as long as I could prevent our 2 main competitors from using my modules? :-)

You currently provide two examples, the simple text file (AbstractNativeFileParser) and the bilingual file (IMarkupDataVisitor). Which both work pretty differently. Maybe whats missing is maybe something that works like the bilingual example, but with only one language in a file. E.g. a simple XML or HTML file.

Remy Blaettler said:

One big issue with these custom import filters is, that if you create a package and the translator does not have the filter installed, he cannot translate it.

Hi Remy,

This must be incorrect?  If you create a package then the file is already an sdlxliff in the package and because the package was created from the project containing this custom filetype then the translator can also use this for creation of the target as needed.

I can't comment on the examples in the SDK, but perhaps Ian can do this when he reads the thread.

Regards

Paul

-- from what I remember you can reference the project template while creating the project, from which the package can be created from;  all the filetypes present in the project template should be included in the package.

example:

                ProjectTemplateReference ProjectTemplateReferencePath = new ProjectTemplateReference(projectTemplatePath);
                FileBasedProject newProject = new FileBasedProject(GetProjectInfo(projectFolder, projectName, srcLocale, trgLocale), ProjectTemplateReferencePath);

> If you create a package then the file is already an sdlxliff in the

> package and because the package was created from the project

> containing this custom filetype

Well, from the business perspective this is actually a problem (and has been in TagEditor times as well). E.g. you might have spend a lot of time and money to create a custom xml filter with all finesse like complex xpath expressions, document tree structure, preview etc. And of course as an LSP you actually do not want to deploy this custom file filter to the whole translation supply chain.

I strongly recommend to make SDLXLIFF more "stand-alone". The file format filters should be completely independent of the translation file format SDLXLIFF. Once the SDLXLIFF is created there should be no need to send the filter out into the world.

This is especially important if we want to actually sell custom xml filters.

Cheers,

*Stefan.

Besides, I would also be interested in creating a MemoQ XLIFF filter. Maybe Marc could do the transit, we do the MemoQ filter?

I thought this was solved in Studio 2011 since the filetypes are not shipped in the package but the settings are embedded in the sdlxliff or am I missing something here?

Sorry, if I opened a can of worms here, but I just tried it out this morning with the SimpleText file type. I created a project and send the package to my co-worker. And he get the message that this SimpleText file type assembly was not found.

Maybe I'm doing something wrong?

Hi,

once you convert your custom file type into SDL XLIFF using your custom file type you can create a package and send it to anybody - Studio will allow the file to be translated and you can perform all activities as usually but:

- you will not be able to preview file in case your custom filter has special preview

- you will not be able to save as source or target

This is quite obvious as when you implement a special functionality into new assembly which is not present on the other PC you cannot expect us to provide functionality which will handle it.

What actually happens is that the package contains the settings for your custom filter so in case the other PC has the filter installed the settings are properly passed through.

You mentioned that the filters should be part of the package - we decided against this for various reasons:

- filter usualy is not just one file and there will be requirement to actually create a new mechanism to handle this situation (to make sure everything is packed up)

- even when we make sure all files are packed up the filter can be using some 3rd party application

- users had a big concerns about few KB the settings XML files when we used the older mechanism when settings were exposed as XMLs and part of each project - not sure how they will react when we actually pack all filters in it.

Regards

Patrik

Dear Ralph,

I will look on this issue - something is not right - is there any special thing I should know about the package?

Regards

Patrik

Hi,

one more note - as Paul found - these limitations only apply to real custom filters not to filters you create inside Studio like customized HTML, XML etc. For these filters all functionality will be fully functional - and user will not be prompted for specifying the settings file (as the settigns is part of the package).

Patrik