Please sign in to see the alerts.

Overview

Project website postgis.net
Translation process
  • Translations can be made directly.
  • Translation suggestions can be made.
  • Any authenticated user can contribute.
  • The translation uses bilingual files.
Source code repository https://git.osgeo.org/gitea/postgis/postgis.git
Repository branch stable-3.2
Last remote commit Push to 3.2.6dev milestone 6e2c5206d
Regina Obe authored 11 days ago
Weblate repository https://weblate.osgeo.org/git/postgis_branch_32/postgis/
File mask doc/po/*/administration.xml.po

String statistics

Strings percent Hosted strings Words percent Hosted words Characters percent Hosted characters
Total 783 17,865 131,670
Source 87 1,985 14,630
Translated 11% 87 11% 1,985 11% 14,630
Needs editing 0% 0 0% 0 0% 0
Read-only 11% 87 11% 1,985 11% 14,630
Failing checks 1% 3 1% 200 1% 1,651
Strings with suggestions 23% 183 22% 4,049 22% 29,930
Untranslated strings 88% 696 88% 15,880 88% 117,040
Last 12 months Previous

Activity in last 12 months

0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 30 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 906 changes 51 changes
Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May

Quick numbers

17,865
Hosted words
783
Hosted strings
11%
Translated
2
Contributors
and previous 30 days

Trends of last 30 days

—
Hosted words
—
—
Hosted strings
—
—
Translated
—
+100%
Contributors
—
User avatar anonymous

Suggestion added

postgis_branch_32 / administration — French

psql -h localhost -p 5432 -U postgres -d newdb -f olddb-without-IGN.sql 2> errors.txt
psql -h localhost -p 5432 -U postgres -d newdb -f olddb-without-IGN.sql 2> errors.txt
3 weeks ago
User avatar anonymous

Suggestion added

postgis_branch_32 / administration — French

In order to fix this you should copy your custom SRS to a SRID with a valid value (maybe in the 910000..910999 range), convert all your tables to the new srid (see <xref linkend="UpdateGeometrySRID"/>), delete the invalid entry from spatial_ref_sys and re-construct the check(s) with: <programlisting>ALTER TABLE spatial_ref_sys ADD CONSTRAINT spatial_ref_sys_srid_check check (srid &gt; 0 AND srid &lt; 999000 );</programlisting> <programlisting>ALTER TABLE spatial_ref_sys ADD PRIMARY KEY(srid));</programlisting> If you are upgrading an old database containing french <ulink url="https://en.wikipedia.org/wiki/Institut_g%C3%A9ographique_national"> IGN </ulink> cartography, you will have probably SRIDs out of range and you will see, when importing your database, issues like this : <programlisting> WARNING: SRID 310642222 converted to 999175 (in reserved zone)</programlisting> In this case, you can try following steps : first throw out completely the IGN from the sql which is resulting from postgis_restore.pl. So, after having run : <programlisting>perl utils/postgis_restore.pl "/somepath/olddb.backup" > olddb.sql</programlisting> run this command : <programlisting>grep -v IGNF olddb.sql > olddb-without-IGN.sql</programlisting> Create then your newdb, activate the required Postgis extensions, and insert properly the french system IGN with : <ulink url="https://raw.githubusercontent.com/Remi-C/IGN_spatial_ref_for_PostGIS/master/Put_IGN_SRS_into_Postgis.sql"> this script </ulink> After these operations, import your data :
Pour résoudre ce problème, vous devez copier votre SRS personnalisé dans un SRID avec une valeur valide (peut-être dans la plage 910000..910999), convertir toutes vos tables au nouveau SRID (voir <xref linkend="UpdateGeometrySRID"/>), supprimer l'entrée invalide de spatial_ref_sys et reconstruire le(s) contrôle(s) à l'aide de : <programlisting>ALTER TABLE spatial_ref_sys ADD CONSTRAINT spatial_ref_sys_srid_check check (srid &gt; 0 AND srid &lt; 999000 );</programlisting> <programlisting>ALTER TABLE spatial_ref_sys ADD PRIMARY KEY(srid));</programlisting> Si vous mettez à niveau une ancienne base de données contenant des <ulink url="https://en. wikipedia.org/wiki/Institut_g%C3%A9ographique_national"> IGN </ulink> cartographie française, vous aurez probablement des SRID hors plage et vous verrez, lors de l'importation de votre base de données, des problèmes comme celui-ci : <programlisting> WARNING : SRID 310642222 converted to 999175 (in reserved zone)</programlisting> Dans ce cas, vous pouvez essayer les étapes suivantes : d'abord supprimer complètement l'IGN du sql qui résulte de postgis_restore.pl. Ainsi, après avoir exécuté : <programlisting>perl utils/postgis_restore.pl "/somepath/olddb.backup" > olddb.sql</programlisting> lancer cette commande : <programlisting>grep -v IGNF olddb.sql > olddb-without-IGN.sql</programlisting> Créez ensuite votre newdb, activez les extensions Postgis nécessaires, et insérez correctement l'IGN du système français avec : <ulink url="https://raw.githubusercontent.com/Remi-C/IGN_spatial_ref_for_PostGIS/master/Put_IGN_SRS_into_Postgis.sql"> ce script </ulink> Après ces opérations, importez vos données :
3 weeks ago
User avatar anonymous

Suggestion added

postgis_branch_32 / administration — French

Some custom records of spatial_ref_sys in dump file have an invalid SRID value. Valid SRID values are bigger than 0 and smaller than 999000. Values in the 999000.999999 range are reserved for internal use while values > 999999 can't be used at all. All your custom records with invalid SRIDs will be retained, with those > 999999 moved into the reserved range, but the spatial_ref_sys table would lose a check constraint guarding for that invariant to hold and possibly also its primary key ( when multiple invalid SRIDS get converted to the same reserved SRID value ).
Certains enregistrements personnalisés de spatial_ref_sys dans le fichier dump ont une valeur SRID invalide. Les valeurs SRID valides sont supérieures à 0 et inférieures à 999000. Les valeurs comprises entre 999000 et 999999 sont réservées à un usage interne, tandis que les valeurs supérieures à 999999 ne peuvent pas être utilisées. Tous vos enregistrements personnalisés avec des SRID invalides seront conservés, avec ceux > 999999 déplacés dans la plage réservée, mais la table spatial_ref_sys perdrait une contrainte de contrôle protégeant cet invariant et peut-être aussi sa clé primaire (lorsque plusieurs SRIDS invalides sont convertis en la même valeur SRID réservée).
3 weeks ago
User avatar anonymous

Suggestion added

postgis_branch_32 / administration — French

Some of your views or functions make use of deprecated PostGIS objects. In order to fix this you may try loading <filename>legacy.sql</filename> script prior to restore or you'll have to restore to a version of PostGIS which still contains those objects and try a migration again after porting your code. If the <filename>legacy.sql</filename> way works for you, don't forget to fix your code to stop using deprecated functions and drop them loading <filename>uninstall_legacy.sql</filename>.
Certaines de vos vues ou fonctions utilisent des objets PostGIS obsolètes. Pour y remédier, vous pouvez essayer de charger le script <filename>legacy.sql</filename> avant la restauration ou vous devrez restaurer vers une version de PostGIS qui contient encore ces objets et réessayer une migration après le portage de votre code. Si la méthode <filename>legacy.sql</filename> fonctionne pour vous, n'oubliez pas de corriger votre code pour arrêter d'utiliser les fonctions dépréciées et de les supprimer en chargeant <filename>uninstall_legacy.sql</filename>.
3 weeks ago
User avatar anonymous

Suggestion added

postgis_branch_32 / administration — French

Errors may arise in the following cases:
Des erreurs peuvent survenir dans les cas suivants :
3 weeks ago
User avatar anonymous

Suggestion added

postgis_branch_32 / administration — French

perl utils/postgis_restore.pl "/somepath/olddb.backup" | psql -h localhost -p 5432 -U postgres newdb 2> errors.txt
perl utils/postgis_restore.pl "/somepath/olddb.backup" | psql -h localhost -p 5432 -U postgres newdb 2> errors.txt
3 weeks ago
User avatar anonymous

Suggestion added

postgis_branch_32 / administration — French

Restore your backup into your fresh <varname>newdb</varname> database using postgis_restore.pl. Unexpected errors, if any, will be printed to the standard error stream by psql. Keep a log of those.
Restaurez votre sauvegarde dans votre nouvelle base de données <varname>newdb</varname> en utilisant postgis_restore.pl. Les erreurs inattendues, s'il y en a, seront imprimées dans le flux d'erreur standard par psql. Conservez un journal de ces erreurs.
3 weeks ago
User avatar anonymous

Suggestion added

postgis_branch_32 / administration — French

If your database is really old or you know you've been using long deprecated functions in your views and functions, you might need to load <filename>legacy.sql</filename> for all your functions and views etc. to properly come back. Only do this if _really_ needed. Consider upgrading your views and functions before dumping instead, if possible. The deprecated functions can be later removed by loading <filename>uninstall_legacy.sql</filename>.
Si votre base de données est très ancienne ou si vous savez que vous avez utilisé des fonctions dépréciées depuis longtemps dans vos vues et fonctions, vous devrez peut-être charger <filename>legacy.sql</filename> pour que toutes vos fonctions, vues, etc. reviennent correctement. Ne le faites que si c'est _vraiment_ nécessaire. Envisagez plutôt de mettre à jour vos vues et fonctions avant de faire le dumping, si possible. Les fonctions dépréciées peuvent être supprimées plus tard en chargeant <filename>uninstall_legacy.sql</filename>.
3 weeks ago
User avatar anonymous

Suggestion added

postgis_branch_32 / administration — French

The spatial_ref_sys entries found in your dump will be restored, but they will not override existing ones in spatial_ref_sys. This is to ensure that fixes in the official set will be properly propagated to restored databases. If for any reason you really want your own overrides of standard entries just don't load the spatial_ref_sys.sql file when creating the new db.
Les entrées spatial_ref_sys trouvées dans votre dump seront restaurées, mais elles ne remplaceront pas les entrées existantes dans spatial_ref_sys. Cela permet de s'assurer que les corrections du jeu officiel seront correctement propagées dans les bases de données restaurées. Si, pour une raison quelconque, vous souhaitez vraiment que vos propres entrées standard soient remplacées, ne chargez pas le fichier spatial_ref_sys.sql lors de la création de la nouvelle base de données.
3 weeks ago
User avatar anonymous

Suggestion added

postgis_branch_32 / administration — French

Do a fresh install of PostGIS in a new database -- we'll refer to this database as <varname>newdb</varname>. Please refer to <xref linkend="create_new_db"/> and <xref linkend="create_new_db_extensions"/> for instructions on how to do this.
Effectuez une nouvelle installation de PostGIS dans une nouvelle base de données - nous appellerons cette base de données <varname>newdb</varname>. Veuillez vous référer à <xref linkend="create_new_db"/> et <xref linkend="create_new_db_extensions"/> pour les instructions sur la façon de procéder.
3 weeks ago
Browse all component changes