Werkt dit niet meer ?

$Source: $
$Revision: $
$Date: $

Even een persoonlijke 'visie'..

Of het niet werkt, eerlijk : geen idee.
Het is (neem aan dat je bedoelt het gebruik ervan in de taalbestanden), niet of nauwelijks meer in gebruik.
Dat is correct en is opgetreden na het niet meer gebruiken van deze 'header'opties in de orignele engelse bestanden.
Men raakt inderdaad de revisienummers kwijt, maar weet (in relatie tot de origine) wat je kunt gebruiken als revisienr. ook de bron niet exact. Een en nader is ook de verplaatsing van SourceForge 'bronserver' (wordt wel nog gebruikt als soort opslag en download area door org), maar gebeurt ( oorzaak verplaatsing taalgebied , bron, verwerking toegang en bewerking door contributers). (is ook een eenvoudigere rechten voor gebruikers...instelling).

Wij gebruiken zelf als tussenstation wel nog SF, zodat we steeds allen direct kunnen zien wie wat heeft gedaan (opzet). Of (zakelijkheid) SF blijft bestaan (soms geruchten) is nog altijd onduidelijk omdat de algemen shift richting Github gaat.
Stel source is sf (die kan zelf wel nummers meegeven), blijft het een zaak of en hoe je daar mee wil omgaan.
Gezien dus dat een en ander ook niet door anderen niet meer actief wordt bijgehouden, raakt het gebeuren in verval, en verdwijnt daar door uit de taalbestanden.

Ik begrijp dat bij naspeuringen een en ander voor vergelijking of fout opspeuring handig kan zijn, maar ongeacht op SF of Git middels historie (ja is werk) alles tot 'eerder' in historie (commits) is te achterhalen.
Nadelig aan het gebruik is ook bij snelle veranderingen misschien (taal define is en blijft belangrijkst), dat een en ander vergeten wordt met aanpassen), wat ook weer invloed heeft bij naspeuring.
Een en ander wordt dan gedragen door de versie pakketten, die dit eigenlijk op zichzelf ook weer vergeleken kunnen worden..
Algemene indruk is (imo) waarom nog gebruiken, is alleen maar 'publiekelijk onzichtbare data, die 'toch' alleen maar door de vertalers gebruikt kan en zal worden. Verder is (stelt eigenlijk helemaal niks voor) datagrootte, en het voorkomen van php (code) fouten...

Allemaal bedenkingen die optreden kunnen... Is het goed of fout en heeft het nog nut? Voor en nadelen (wens en gebruik) verschillen, omdat ook de huidige generaties vertalers steeds schuiven (en of zij ook weer de source en revnr's willen/zullen gebruiken ??? Who am i ?. Ik probeer alleen maar een toelichting te geven, geen rechten of verplichtingen of voorgeschreven wijze hierin.

In relatie tot het bovenstaande (vraagstelling, en een antwoord daarop heeft mij aan het denken gezet.
Zeker in verband met de historie daaraan gekoppeld.

Bij mij ontstaat het idee om de huidige NL vertalingen (voor hen die SF gebruiken), er een nieuwe onderverdeling aanmaken.

Of een en ander dadelijk (idee/vermoeden) steeds meer gaat afwijken van de oudere versies inzake BC compatibiliteit,
lijkt het mij NU de aangewezen tijd dit eventueel te doen.

Versie 2.3.1 is dermatige structureel aan het veranderen (grote invloed van php 8 in verband met define constants) : plugins erbij, andere eruit (er blijven dan OF oude in het pakket of verdwijnen, en nieuwe komen erbij), of het misschien dan dus niet beter is de eerdere versie te 'backuppen' , en vanaf dat punt verder door te gaan (nieuwe trunk start dan met v 2.3.1 en tot aan die versie in de backup).

Heeft iemand hierover een mening ?

Mijn taal bestand is nog steeds actueel maar snap weinig github...

Jaja Github, in principe bijna gelijk, maar andere gebruikswijzie en functies (sommige + andere -).
Het taalpakket wat wie nou samenstellen loopt (als wordt bijgewerkt, steeds gelijk op.
Echter is de trunk op SF een 'continue' proces maw een doorontwikkeling.

Daartegen maakt e107 dan nu (ook voor admin gebruik/syncen) steeds gebruik van een pakket gerelateerd aan een IN TIJD gebonden pakket op github.
Als groot voorbeeld : SF heeft 1 pakket (code deel) = nagenoeg altijd up to date.
Ga je kijken op Git-transl. heeft NL bijv 10 uitgaves + 1 in bewerking Dus hier zijn per uitgave verschillen.
Dat is het eigenlijk.
Voordeel voor Git is dan tegenwoordig, dat ik een bestand direct online kan bewerken, waarbij ik voor SF de bestanden 'thuis' klaarmaak, en die upload. Of sf ook direct edit ondersteund.. nooit gezien.