W dniu 25.01.2016 o 03:29, Andriy Rysin pisze: > Currently 95% of the language handling is done in language module so > when I edit segment.srx I need to remember to recompile/redeploy > languagetool-core.
Make a script ;) > > If we're using segment.srx only inside languagetool I don't see how > we're breaking the standard if we compose the full segment.srx file > from the language modules when we need it. And if somebody wants to > have full segment.srx for using outside of LT we could add a target to > build in, e.g. in languagetool-tools. The file is relatively small. Why would we really want it – just to make sure that you don't have to remember to recompile languagetool-core? ;) I just don't see a need. > This would help LT being more modular, which for most of the software > is a good architectural approach. Your approach is to build complicated tools just to solve an issue that is a matter of taste. This is a waste of time. It would be much more productive to build more GUI tools. Regards, Marcin > > Regards, > Andriy > > > > 2016-01-24 17:13 GMT-05:00 Marcin Miłkowski <list-addr...@wp.pl>: >> W dniu 24.01.2016 o 17:15, Andriy Rysin pisze: >>> Would it make sense to split segment.srx into language modules (and >>> assemble dynamically from available languages)? For now it seems to be >>> the only language-specific piece that belongs to core module. >>> Was there any attempts at this and if yes what was the obstacle? >> >> No, there were no attempts because it's against the official >> specifications of the SRX standard. The SRX file is supposed to work for >> all languages that a given software application can support. This is how >> SRX files in general look in all computer-aided translation apps, for >> example. >> >> Note also that SRX contains a several common parts that all languages >> inherit (such as splitting paragraphs at one or two line breaks), so >> this file is cascading. >> >> I just don't see a point in splitting. Is there an ideological point >> that the core should be language-independent? I don't think we should >> care about it. >> >> Regards, >> Marcin >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 >> _______________________________________________ >> Languagetool-devel mailing list >> Languagetool-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/languagetool-devel > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Languagetool-devel mailing list > Languagetool-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/languagetool-devel > ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
