[
https://issues.apache.org/jira/browse/TIKA-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901231#action_12901231
]
Jukka Zitting commented on TIKA-490:
------------------------------------
I wonder why we'd need these extra properties files in the first place. As an
alternative, how about if we just added an optional Map<String,
LanguageProfile> argument to the LanguageIdentifier constructors, so
applications that want to add new languages or customize the default profiles
can easily do so. Such an approach would be much more flexible and less
error-prone (no need for extra logging) than using properties files, and an
application that needs runtime configuration of language profiles can still
implement its own properties files for this purpose.
> Support for adding language profiles dynamically
> ------------------------------------------------
>
> Key: TIKA-490
> URL: https://issues.apache.org/jira/browse/TIKA-490
> Project: Tika
> Issue Type: Improvement
> Components: languageidentifier
> Affects Versions: 0.7
> Reporter: Jan Høydahl
> Assignee: Chris A. Mattmann
> Fix For: 0.8
>
> Attachments: TIKA-490.janhoy.082310.patch,
> TIKA-490.janhoy.082310.patch, TIKA-490.Mattmann.082210.2.patch.txt,
> TIKA-490.Mattmann.082210.patch.txt, TIKA-490.patch, TIKA-490.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Currently the Tika LanguageIdentifier loads language profiles thorugh a
> hardcoded static block in the java code.
> It would be better to make this configurable, so you could add your own
> languages without recompiling.
> Suggested approach:
> Remove the static code block loading all languages. Instead look for a
> tika.languageidentification.properties file on classpath.
> Now the user can simply make his/her own (additional) language profile files,
> put them on the classpath together with a properties file and off you go!
> Also, once you make it configurable, there might be an issue of having the
> profiles as static members, as you will force the same behaviour for the
> whole VM. A static Map of Maps could solve this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.