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 <jody.garn...@gmail.com> 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 you mean two properties files; or two >> entries in the same property file. Or two entries in different property >> files? >> >> I am guessing you mean two property files for the chinese language; where >> we followed some wicket convention for having property files in different >> encodings. I think we should just use the utf8 encoding? Which is not a >> java standard but wicket supports it. >> >> - >> https://github.com/geoserver/geoserver/blob/main/src/web/wms/src/main/resources/GeoServerApplication.properties >> - >> https://github.com/geoserver/geoserver/blob/main/src/web/wms/src/main/resources/GeoServerApplication_zh.properties >> - >> https://github.com/geoserver/geoserver/blob/main/src/web/wms/src/main/resources/GeoServerApplication_zh_CN.utf8.properties >> >> My understanding is we should keep the utf8 properties if weblate is >> willing to understand utf8 encoding?? >> >> About replacing text with unicode; not sure how that works with java >> properties being specified in a in ISO-8859-1 as part of the java api. >> -- >> Jody Garnett >> >> >> On Wed, 10 Aug 2022 at 23:11, Alexandre Gacon <alexandre.ga...@gmail.com> >> wrote: >> >>> Hi all, >>> >>> I am studying if we could migrate the translation tooling from Transifex >>> to Weblate. I have started this because with the current setup >>> Transifex is changing a lot of translations when I upload updates of the >>> translation source, making it difficult to do the synchronization between >>> GitHub and Transifex. >>> >>> Weblate is a copyleft libre software and OSGeo is hosting its own >>> instance, already used by several OSGeo projects (postgis, pgrouting and >>> grass gis at least). >>> >>> Thanks to Regina Obe, I have set up a GeoServer project on the OSGeo >>> instance to study how weblate works and if there is something which can >>> prevent us from using it. >>> >>> I have already two points to share with you to get some feedback: >>> >>> - First, when you configure a component into weblate, you cannot >>> have two items for the same language, even if they are in a different >>> encoding. As a consequence, I cannot directly integrate most of the core >>> components since they contain 2 files for the Chinese language: is it >>> something which can be changed? Which one is used by GeoServer? >>> - Second, when you change the translation of a text in weblate, it >>> automatically replaces special characters by their equivalent in unicode, >>> even if the character exists in the ISO-8859-1 encoding. For example: >>> >>> org.geoserver.security.GeoServerAuthenticationKeyFilter.name=Clé >>> d'authentification >>> is replaced by >>> org.geoserver.security.GeoServerAuthenticationKeyFilter.name=Cl\u00E9 >>> d'authentification >>> >>> (my own change in the translation was to add a space at the end of the >>> string, to match the original layout of the source string) >>> >>> From a technical point of view, it does not break anything but it would >>> make it more difficult to work on a translation without using weblate. >>> >>> Do you see any problems around these two points? Anything else to check? >>> >>> >>> -- >>> Alexandre Gacon >>> _______________________________________________ >>> Geoserver-devel mailing list >>> Geoserver-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>> >> > > -- > Alexandre Gacon > -- Alexandre Gacon
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
