Re: [Geoserver-devel] Use OSGEO weblate as translation tool - Development consequences
Hi, For the UTF-8 file for Chinese, the Transifex update does not apply to it but only to the one in ISO-8859 encoding : could I remove them from the source code? I just gave another try to Transifex and I still have unwanted changes (translations removed without asking it): it will give a lot of work to check things at each update so I am clearly in favor of moving to the osgeo weblate instance (another advantage I discovered recently is that with the GitHub integration 1) it is no longer required to use a local dev environment to synchronize source and translation and 2) administrators are informed of sources to get updated). I will do a last check on the different configuration options to write down which options we would like to take. I will freeze the translations on Transifex meanwhile. Alexandre Le lun. 15 août 2022 à 16:10, Jody Garnett a écrit : > If you wish to choose weblate I am sure we can work with what it does > > On Mon, Aug 15, 2022 at 12:12 AM Alexandre Gacon < > alexandre.ga...@gmail.com> wrote: > >> Hi Jody, >> >> I had a look at the git history for the UTF8 file: the file was created >> by you by renaming the CN ISO file ( >> https://osgeo-org.atlassian.net/browse/GEOS-10282). If I understand the >> JIRA issue correctly, this was related to the encoding issue in the >> translation files (the same old story) and the idea was perhaps to migrate >> all the translations to UTF-8 encoding. >> >> Weblate UI manages to display the characters in all options: >> - ISO-8859 characters in ISO-8859 encoded file >> - U encoded characters (\u00e9 for example) in ISO-8859 encoded file >> - UTF-8 file >> >> Weblate can read and write either ISO-8859 files or UTF-8 files but >> inside for a given component you can have only one of the two options. For >> ISO-8859 files, weblate can read either ISO-8859 characters (é) and U >> encoded characters (\u00e9) but when you change a translation, it will >> always be written in U encoded characters. >> >> Regards >> Alexandre >> >> Le ven. 12 août 2022 à 21:46, Jody Garnett a >> écrit : >> >>> You may have to search back in the geoserver-devel history or bug >>> tracker for details. I assume we were provided utf8 translations and wished >>> to preserve them? >>> >>> When using the UI in weblate can folks see the native characters >>> regardless of encoding used? >>> >>> What I remember is that we needed UTF8 to support some >>> chinese characters; but the java properties file format is ISO-8859-1 (like >>> the actual format on disk). >>> Wicket had some naming convention where you could append utf8 to the >>> filename - but no other tools understand this. >>> >>> If I understand you correctly: >>> - Weblate wants to work with UTF8 if it can? >>> - Java properties file want ISO-8859-1 >>> >>> Is there any way to hint to weblate what encoding to use? Looks like yes >>> https://docs.weblate.org/no/latest/formats.html#java-properties >>> I cannot tell from that page if you can choose the encoding of >>> individual property files (ie do this manually)? >>> >>> Following links weblate uses >>> http://docs.translatehouse.org/projects/translate-toolkit/en/latest/formats/properties.html >>> >>> Which uses: >>> - >>> http://docs.translatehouse.org/projects/translate-toolkit/en/latest/commands/prop2po.html >>> >>> Reading through those docs there is an option "--personality=mozilla" >>> which would preserve UTF8 characters rather than force them into Latin1 >>> encoding. >>> -- >>> Jody >>> >>> >>> On Fri, 12 Aug 2022 at 04:25, Alexandre Gacon >>> wrote: >>> I try to keep only the UTF-8 file as the source for Chinese, along with the other languages in ISO-8859-1: the display of the file content in weblate is totally broken. I have to define another fake component configured to support UTF-8 encoding to be able to manage it correctly. What is the reason to keep the two encoding? Alexandre Le ven. 12 août 2022 à 08:26, Alexandre Gacon < alexandre.ga...@gmail.com> a écrit : > Hi Jody, > > You are guessing well: it is all about the Chinese language : for > weblate it is the same language defined twice so it cannot cope with it. > > I have to check how weblate can work with having one of the languages > in UTF-8 whereas the other ones are in ISO-8859-1 : I fear that it will > mean to have two components side by side. > > For your last point, it seems to work well for ages: Romanian is > mixing both characters encoding whereas Japanese and Korean are totally > with unicode characters inside a ISO-8859-1 encoded file. > > Alexandre > > Le jeu. 11 août 2022 à 20:36, Jody Garnett a > écrit : > >> Weblate is a good idea; we held back perviously because of lack of >> hosting. However if OSGeo is able to host :) >> >> I do not understand about two items for the same language: can you >> provide links in the github repo? Do
Re: [Geoserver-devel] JDBC Store implementation guidelines
Jody, a draft PR is available here : https://github.com/geoserver/geoserver/pull/6121. Le ven. 19 août 2022 à 10:04, Alexandre Gacon a écrit : > I will do that after doing some additional investigation on my side. > > Alexandre > > Le ven. 19 août 2022 à 09:58, Jody Garnett a > écrit : > >> If you make a draft PR I am happy to provide input. I presently do not >> have any customers using JDBCStore but I am happy to support your >> troubleshooting. >> >> If I remember it really just wants a data structure for configuration; >> and it needs to callback to the geoserver catalogue to look up data stores >> being referenced. >> >> Good fun. >> — >> Jody >> >> On Fri, Aug 19, 2022 at 08:53 Alexandre Gacon >> wrote: >> >>> Thanks Jody for the input. I have already implemented a first version >>> (which of course does not work) and I will have a look at the examples to >>> see what I did wrong. >>> >>> Alexandre >>> >>> Le ven. 19 août 2022 à 08:49, Jody Garnett a >>> écrit : >>> Alexandre: The original proposal had example code snippets; and I did my best to add very good javadocs for using ResourceStore. - https://github.com/geoserver/geoserver/wiki/GSIP-106 - https://github.com/geoserver/geoserver/wiki/ResourceStore-API-Examples As shown in the examples it is really nice if you can adapt your code to use input streams directly; but the method file() is available that unpacks the file to the local data directory location for code (such as our freemarker template engine which really wanted a local file). -- Jody On Wed, Aug 17, 2022 at 4:07 PM Alexandre Gacon < alexandre.ga...@gmail.com> wrote: > Hello, > > Is there any guideline on how to evolve an existing module to make it > compatible with the jdbcstore community extension? > > I need to use the feature-pregeneralized extension with this store and > for the moment it does not work. > > The extension currently uses the Resources.find method to find a > reference to the configuration file: I assume I shall change the code to > use a class derived from > org.geoserver.platform.resource.ResourceStore > > instead > > -- > Alexandre Gacon > ___ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > -- -- Jody Garnett >>> >>> >>> -- >>> Alexandre Gacon >>> >> -- >> -- >> Jody Garnett >> > > > -- > Alexandre Gacon > -- Alexandre Gacon ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] JDBC Store implementation guidelines
I will do that after doing some additional investigation on my side. Alexandre Le ven. 19 août 2022 à 09:58, Jody Garnett a écrit : > If you make a draft PR I am happy to provide input. I presently do not > have any customers using JDBCStore but I am happy to support your > troubleshooting. > > If I remember it really just wants a data structure for configuration; and > it needs to callback to the geoserver catalogue to look up data stores > being referenced. > > Good fun. > — > Jody > > On Fri, Aug 19, 2022 at 08:53 Alexandre Gacon > wrote: > >> Thanks Jody for the input. I have already implemented a first version >> (which of course does not work) and I will have a look at the examples to >> see what I did wrong. >> >> Alexandre >> >> Le ven. 19 août 2022 à 08:49, Jody Garnett a >> écrit : >> >>> Alexandre: >>> >>> The original proposal had example code snippets; and I did my best to >>> add very good javadocs for using ResourceStore. >>> - >>> https://github.com/geoserver/geoserver/wiki/GSIP-106 >>> - >>> https://github.com/geoserver/geoserver/wiki/ResourceStore-API-Examples >>> >>> As shown in the examples it is really nice if you can adapt your code to >>> use input streams directly; but the method file() is available that unpacks >>> the file to the local data directory location for code (such as our >>> freemarker template engine which really wanted a local file). >>> >>> -- >>> Jody >>> >>> On Wed, Aug 17, 2022 at 4:07 PM Alexandre Gacon < >>> alexandre.ga...@gmail.com> wrote: >>> Hello, Is there any guideline on how to evolve an existing module to make it compatible with the jdbcstore community extension? I need to use the feature-pregeneralized extension with this store and for the moment it does not work. The extension currently uses the Resources.find method to find a reference to the configuration file: I assume I shall change the code to use a class derived from org.geoserver.platform.resource.ResourceStore instead -- Alexandre Gacon ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>> -- >>> -- >>> Jody Garnett >>> >> >> >> -- >> Alexandre Gacon >> > -- > -- > Jody Garnett > -- Alexandre Gacon ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] JDBC Store implementation guidelines
If you make a draft PR I am happy to provide input. I presently do not have any customers using JDBCStore but I am happy to support your troubleshooting. If I remember it really just wants a data structure for configuration; and it needs to callback to the geoserver catalogue to look up data stores being referenced. Good fun. — Jody On Fri, Aug 19, 2022 at 08:53 Alexandre Gacon wrote: > Thanks Jody for the input. I have already implemented a first version > (which of course does not work) and I will have a look at the examples to > see what I did wrong. > > Alexandre > > Le ven. 19 août 2022 à 08:49, Jody Garnett a > écrit : > >> Alexandre: >> >> The original proposal had example code snippets; and I did my best to add >> very good javadocs for using ResourceStore. >> - >> https://github.com/geoserver/geoserver/wiki/GSIP-106 >> - >> https://github.com/geoserver/geoserver/wiki/ResourceStore-API-Examples >> >> As shown in the examples it is really nice if you can adapt your code to >> use input streams directly; but the method file() is available that unpacks >> the file to the local data directory location for code (such as our >> freemarker template engine which really wanted a local file). >> >> -- >> Jody >> >> On Wed, Aug 17, 2022 at 4:07 PM Alexandre Gacon < >> alexandre.ga...@gmail.com> wrote: >> >>> Hello, >>> >>> Is there any guideline on how to evolve an existing module to make it >>> compatible with the jdbcstore community extension? >>> >>> I need to use the feature-pregeneralized extension with this store and >>> for the moment it does not work. >>> >>> The extension currently uses the Resources.find method to find a >>> reference to the configuration file: I assume I shall change the code to >>> use a class derived from >>> org.geoserver.platform.resource.ResourceStore >>> >>> instead >>> >>> -- >>> Alexandre Gacon >>> ___ >>> Geoserver-devel mailing list >>> Geoserver-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>> >> -- >> -- >> Jody Garnett >> > > > -- > Alexandre Gacon > -- -- Jody Garnett ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
